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ABSTRACT 


Converging  voice  and  data  networks  has  the  potential 
to  save  money  and  is  the  main  reason  Voice  over  Internet 
Protocol  (VoIP)  is  quickly  becoming  mainstream  in  corporate 
America.  The  potential  VoIP  offers  to  more  efficiently 
utilize  the  limited  connectivity  available  to  ships  at  sea 
makes  it  an  attractive  option  for  the  Navy.  This  thesis 
investigates  the  usefulness  of  VoIP  for  the  communications 
needs  of  a  unit  level  ship.  This  investigation  begins  with 
a  review  of  what  VoIP  is  and  then  examines  the  ship  to 
shore  connectivity  for  a  typical  unit  level  ship.  An 
OMNeT++  model  was  developed  and  used  to  examine  the  issues 
that  affect  implementing  VoIP  over  this  type  of  link  and 
the  results  are  presented. 
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INTRODUCTION 


I . 

A.  WHAT  IS  CONVERGENCE 

Convergence  is  the  integration  of  voice,  data,  video, 
or  any  other  imaginable  multimedia  communication  onto  a 
single  transmission  media.  This  may  seem  like  a  lofty  and 
futuristic  goal,  but  the  ideas  of  convergence  are  not  new. 
Convergence  has  been  talked  about  since  the  1980' s  when 
Integrated  Services  Digital  Network  (ISDN)  was  first 
introduced  for  sharing  a  transmission  line  between  data  and 
voice.  Additionally,  in  the  1990' s,  the  phone  companies 
underwent  a  major  upgrade  to  their  backbone  systems.  They 
transitioned  to  packetized  voice  on  their  trunks  in  order 
to  more  efficiently  utilize  available  bandwidth.  The 

potential  that  VoIP  offers  to  more  efficiently  utilize  the 
limited  connectivity  available  to  ships  at  sea  makes  it  an 
attractive  option  for  the  Navy.  In  recent  years,  a  renewed 
emphasis  on  convergence  has  been  seen  in  the  form  of  Voice 
over  Internet  Protocol  (VoIP)  .  VoIP  refers  to  the 

transmission  of  packetized  voice  traffic  on  a  network 
traditionally  designed  for  data.  VoIP  provides  Phone-to- 
Phone,  PC-to-PC,  PC-to-Phone,  Phone-to-PC  and  fax-to-fax 
services.  VoIP  is  often  used  synonymously  with  the  terms 

Internet  telephony,  IP  telephony  and  packetized  voice. 

B.  THE  CASE  FOR  VOIP 

The  number  one  driving  factor  behind  most  new 

technology  is  cost  savings.  The  efficiency  of  VoIP  makes 
it  very  cost  effective  for  use  in  industry.  Significant 
savings  are  realized  when  toll  calls  are  transported  via  an 
internet  or  the  Internet^.  Many  organizations,  DoD 

^  The  term  internet  (with  a  lower  case  i)  in  general  refers  to  the 
connection  of  any  two  or  more  separate  networks.  The  term  Internet 
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included,  save  money  by  leasing  connections  used  to  provide 
dedicated  communications.  These  leased  connections  are 
broken  into  64kbit/s  ISDN  channels.  Each  channel  is 
dedicated  as  either  voice  or  data.  Given  that  a  normal 
conversation  contains  approximately  50%  silence,  50%  of  the 
bandwidth  dedicated  to  a  voice  channel  is  wasted.  Data 
transmission  is  also  'bursty'  in  nature.  Considerable 
bandwidth  is  wasted  between  data  transmissions.  By 

combining  the  two  kinds  of  traffic,  the  burst  nature  of 
both  can  be  exploited.  Both  types  of  traffic  can  then 

travel  over  one  line.  This  can  be  translated  into  cost 
savings  by  using  one  dedicated  line  for  both  types  of 
traffic  vice  having  one  line  for  voice  and  another  for 
data . 

Further  savings  come  from  the  reduction  of  maintenance 
costs  associated  with  the  infrastructure  of  two  disparate 
networks.  In  a  traditional  installation  using  Plain  Old 
Telephone  Service  (POTS) ,  separate  organizations  are 
required  to  maintain  the  data  network  and  the  Private 
Branch  Exchange  (PBX) .  Converging  the  voice  and  data 
networks  would  idealistically  eliminate  the  entire 
infrastructure  associated  with  the  legacy  phone  system 
because  all  phone  calls  would  travel  over  the  data  network. 
In  reality,  specialty  VoIP  equipment  will  be  required  but 
still  the  overall  size  of  the  resulting  organization  will 
be  significantly  reduced. 

C.  VOIP  CONSIDERATIONS 

In  simple  terms,  convergence  is  good  because  it  saves 

money;  however,  cost  savings  alone  is  not  always  enough  to 

convince  industry  to  fully  embrace  a  new  technology.  Many 

(with  a  capital  I)  refers  to  the  specific  entity  that  is  publicly 
accessible  and  comprised  of  networks  worldwide. 
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times  the  quality  of  the  services  provided  are  as  important 
as  cost  savings.  For  VoIP  to  be  widely  accepted  and  used, 
the  quality  of  VoIP  service  provided  must  be  at  least  as 
good  at  those  currently  provided  by  the  Public  Switched 
Telephone  Network  (PSTN) .  Jitter  and  delay  are  often  sited 
as  potential  problems  in  the  quality  of  VoIP  and  need  to  be 
addressed.  Also,  users  have  grown  accustomed  to  many 
advanced  features  provided  by  the  PSTN.  These  include 
convenience  features  such  as  Call  Waiting,  Caller  ID,  and 
Call  Transfer,  safety  features  such  as  Enhanced  911,  and 
Military  Unique  Features  such  as  Multi-level  Precedence  and 
Preemption  (MLPP)  .  All  of  these  must  be  incorporated  as 
VoIP  evolves.  Finally,  VoIP  must  be  compatible  with 
existing  data-over-voice  applications  such  as  Modems,  Fax, 
and  STU/STE. 

D.  US  NAVY  VOIP 

For  the  US  Navy,  convergence  is  not  an  easy  task  to 
undertake.  In  contrast  to  most  other  organizations,  a  good 
portion  of  the  Navy  is  unable  to  communicate  with  the  rest 
of  the  world  via  terrestrial  cables.  The  unique  issues 
associated  with  shipboard  communications  while  at  sea  must 
be  considered  when  designing  any  system  for  use  by  the 
fleet.  Currently,  communication  for  the  majority  of  the 
fleet  is  via  low  bandwidth  connections  used  for  both  voice 
and  data.  The  INMARSAT  system  was  introduced  with  the 
intent  of  meeting  emerging  communications  needs  of  the  unit 
level  ships  in  the  fleet.  The  problem  is  that  applications 
designed  for  shore  based  use,  where  bandwidth  is  less  of  an 
issue,  have  been  incorporated  for  use  at  sea.  The  current 
bandwidth  needs  of  the  unit  level  ships  exceed  the  capacity 
of  the  INMARSAT  system  in  its  current  configuration.  This 


3 


thesis  created  and  developed  models  used  to  investigate 
VoIP  in  a  Navy  environment. 

Implementing  VoIP  on  a  satellite  communications  system 
is  not  an  easy  task.  Problems  that  affect  a  high-speed 
terrestrial  network  are  compounded  when  a  satellite  is  in 
the  communications  path.  The  delay  alone,  approximately 
500ms  for  a  single  trip  to  and  from  a  satellite,  is  outside 
of  the  conventional  norm  for  voice  communications. 
Therefore,  the  effects  of  low  bandwidth,  high  latency 
communications  must  be  considered  in  the  evaluation  of 
VoIP.  This  investigation  begins  with  a  review  of  what  VoIP 
is  and  then  examines  the  ship  to  shore  connectivity  for  a 
typical  unit  level  Navy  ship.  A  model  is  then  used  to 
examine  several  issues  associated  with  implementing  VoIP 
over  this  type  of  link  and  the  results  are  presented. 
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II.  BACKGROUND 


VoIP  merges  the  technologies  and  features  of  the 
Public  Switched  Telephone  Network  (PSTN)  and  business 
telephony  systems  with  computer  networking.  To  truly 
understand  how  VoIP  evolved,  it  is  important  to  first 
review  each  of  these  systems.  This  chapter  will  begin  with 
a  brief  history  of  the  PSTN  and  then  covers  current  types 
of  business  telephony  systems.  The  networking  aspects  of 
VoIP  and  the  terms  used  to  describe  them  will  be  discussed 
in  Chapter  III. 

A.  BRIEF  HISTORY  OF  THE  PSTN 

In  1876,  Alexander  Graham  Bell  made  the  first  voice 
transmission  over  an  electrical  wire.  This  first 
transmission  was  between  two  locations  connected  via  a 
single  wire.  In  the  early  days  of  the  telephone,  each  user 
had  to  be  directly  connected  to  every  other  user.  Figure  1 
shows  the  direct  connection  of  eight  telephones. 


Figure  1 :  Physical  Cable  Between  all  Telephone  Users 
(From  Davidson  &  Peters,  2000) 


5 


The  number  of  connections  required  can  be  determined 


by  the  following  equation: 

#  of  connections  =  n(n-l)/2 
where  n  is  the  number  of  users  in  the  system 


For  this  system  with  eight  users,  28  connections  are 
required.  As  n  increases,  this  system  can  quickly  become 
unwieldy  and  quite  costly. 

The  solution  to  this  problem  was  to  create  a  switch. 
All  of  the  physical  lines  were  run  to  a  central  location 
and  an  operator  routed  the  calls  by  using  a  patch  cord  to 
physically  connect  users  to  each  other.  Since  the  switches 
could  be  connected  to  other  switches,  telephone  networks 
could  be  scaled  up  to  cover  a  greater  geographic  area.  In 
the  1890' s,  an  advance  in  switching  technology  enabled 
switch-to-switch  calling  without  an  operator.  However, 
well  into  the  second  half  of  the  20^^^  century,  many  calls 
were  still  patched  by  hand.  (Farley,  2004) 

Over  the  years,  many  advances  have  been  made  to 
enhance  the  telephone  networks.  In  1937,  multiplexing  of 
analog  signals  was  introduced.  For  the  first  time, 
multiple  calls  could  be  carried  on  a  single  transmission 
line.  The  impact  was  as  profound  as  the  invention  of  the 
switch.  This  allowed  fewer  cables  to  be  run  and  reduced 
overall  system  cost.  A  further  enhancement  occurred  in 
1963  with  the  introduction  of  digital  transmission 
techniques.  These  digital  techniques  are  the  basis  for  the 
infrastructure  in  use  today. 
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The  current  state  of  the  telephone  industry  is  mixed. 
Although  operator  switched  calls  are  a  thing  of  the  past, 
many  analog  switches  are  still  used  on  the  periphery  of  the 
updated  digital  backbone.  Those  areas  still  using  analog 
switches  do  not  get  any  of  the  benefits  associated  with 
digital  systems. 

This  digital  technology  has  enabled  the  modern  PSTN  to 
be  characterized  by  advanced  digital  features  such  as 
Caller  Id,  Call  Waiting,  Voice  Mail,  and  other  services. 
Audible  delays,  once  common  for  long  distance  calls,  have 
been  greatly  reduced  or  in  most  cases  eliminated  as  calls 
are  now  transmitted  at  the  speed  of  light.  These  services 
have  become  commonplace  and  must  be  accommodated  by  any  new 
technology . 

B.  BUSINESS  TELEPHONY 


Today' s 

business 

telephone 

system 

is 

similar  in 

structure  yet 

more  plentiful  in 

features 

than  the 

PSTN. 

These  systems 

can  be 

classified 

as  one 

of 

five 

types . 

These  are  the  simple  business  line,  the  Centrex  line,  the 
Virtual  Private  Network  (VPN) ,  the  Private  Branch  Exchange 
(PBX) ,  and  the  Key-system.  (Davidson,  2000) 

The  simplest  business  telephone  system  is  the  business 
line.  Provided  by  a  Local  Exchange  Carrier  (LEC) ,  the 

business  line  is  usually  charged  at  a  higher  rate  but  is 

essentially  the  same  as  a  residential  line.  It  is  used  by 
small  businesses  that  do  not  require  a  large  number  of 

features  or  a  large  number  of  users. 

Also  available  from  the  Local  Exchange  Carrier  (LEC) 
is  the  Centrex  line.  This  type  of  system  would  be  used  by 
a  small  business  that  needs  additional  features  not 
available  from  a  regular  business  line.  The  phones  are 
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grouped  into  a  Closed  User  Group  (CUG)  .  This  CUG  provides 
the  business  with  features  such  as  call  transfer,  call 
waiting  and  call  groups. 

A  step  up  from  the  Centrex  is  the  third  type  of 
business  system,  the  Virtual  Private  Network  (VPN) .  The 
VPN  allows  the  user  to  treat  geographically  dispersed  sites 
as  a  Closed  User  Group  (CUG)  .  This  system  is  best  suited 
for  a  medium  sized  business  like  a  department  store  where 
there  are  several  different  geographic  locations  but  still 
not  a  large  volume  of  calls.  It  allows  separate  sites  to 
be  connected  without  the  overhead  maintenance  costs 
associated  with  systems  that  are  more  complex. 

The  Private  Branch  Exchange  (PBX)  is  by  far  the  most 
common  phone  system  used  in  business  today.  The  PBX  gives 
the  company  complete  control  over  the  system  configuration. 
A  business  that  has  a  higher  ratio  of  internal  calls  to 
external  calls  can  purchase  fewer  PSTN  trunks 
(connections) .  If  the  internal  calls  go  to  separate 
locations,  tie-lines  can  be  purchased  to  create  permanent 
connections  thus  reducing  long  distance  charges. 

The  fifth  system  is  known  as  the  Key-system.  It  is 
similar  to  the  PBX  but  generally  used  by  businesses  with 
fewer  than  50  phones.  A  Key-system  costs  less  than  a  PBX, 
in  both  initial  setup  and  maintenance,  but  lacks  the 
ability  to  expand  the  way  a  PBX  system  can.  This  lack  of 
expansion  capability  means  a  business  must  be  fairly  stable 
and  able  to  predict  its  future  needs  when  purchasing  a  Key- 
system  . 

As  previously  mentioned,  many  of  the  features  and 
functions  of  the  Public  Switched  Telephone  Network  (PSTN) 


and  the  business  telephony  systems  used  today  have 
contributed  to  the  makeup  of  VoIP.  Users  of  these  systems 
have  expectations  for  quality  that  need  to  be  present  in 
VoIP.  VoIP,  however,  is  deeply  rooted  in  computer  network 
technology  as  well.  The  next  chapter  explains  the  basics 
of  how  VoIP  works  in  network  terms. 
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III.  HOW  VOICE  OVER  INTERNET  PROTOCOL  (VOIP)  WORKS 


Describing  how  VoIP  works  is  a  difficult  task.  There 
are  two  (2)  major  governing  bodies  that  have  published 
different  standards  and  recommendations  on  how  VoIP  should 
be  implemented.  The  Internet  Engineering  Task  Force  (IETF) 
has  addressed  the  issue  from  a  network  communications  point 
of  view  where  the  International  Telecommunications  Union 
(ITU)  has  published  more  along  the  lines  of  telephone 
systems  technology.  These  different  approaches  do  have 
several  overlapping  or  common  components  but  also  have  some 
incompatible  parts  as  well.  Placing  a  VoIP  call  from  a 
high-level  point  of  view  and  data  transport  from  the 
network-level  point  of  view  are  common  to  both  sets  of 
protocols.  Node-level  implementation  is  where  the  two 
differ.  This  chapter  will  begin  by  presenting  the  high 
level  view  of  placing  a  VoIP  call  followed  by  a  description 
of  data  transport  at  the  network  level.  Finally,  a 
description  of  the  two  differing  node  level  implementations 
is  presented. 

A.  PLACING  A  CALL 

When  placing  a  call  using  VoIP,  the  dial  tone,  touch- 
tone,  ringing,  and  busy  signals  are  all  emulated  by  a 
terminal  or  gatekeeper.  When  a  number  is  dialed,  it  is 
mapped  to  the  IP  address  of  the  phone  to  be  called.  A  call 
setup  protocol  is  then  used.  The  actual  set  up  will  depend 
on  which  of  the  two  governing  bodies'  protocols  are  used. 
The  setup  protocol  locates  the  phone  to  be  called  and  once 
found,  sends  a  signal  to  produce  a  ring.  When  the 
receiving  handset  is  picked  up,  voice  is  digitized  via  an 
analog-to-digital  converter  (ADC) ,  packetized,  encapsulated 
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into  IP  datagrams,  and  sent  across  the  network.  At  the 
receiving  end,  the  IP  encapsulation  is  stripped,  the  data 
stream  is  reassembled,  and  the  digital  signal  is  converted 
to  voice  via  a  digital-to-analog  converter  (DAC) .  Figure  2 
shows  this  call  process. 
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Figure  2:  The  VoIP  Call  Process  (From  Caputo,  2000) 


B.  NETWORK  DATA  TRANSPORT 

Once  a  connection  is  established  in  the  call  process, 
data  is  then  transported  across  the  network.  As  mentioned 
above,  the  method  of  data  transport  is  the  same  regardless 
of  which  governing  bodies'  protocols  or  standards  are  being 
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used.  Data  transport  actually  begins  with  packetizing  data 
in  accordance  with  a  CODEC.  A  CODEC  or  coder/decoder  is  a 
standard  method  for  encoding  and  compressing  data.  Several 
different  CODECs  are  currently  used  for  voice  transmission. 
These  CODECs  are  defined  in  standards  published  by  the 
International  Telecommunications  Union  (ITU). 

The  data  is  then  encapsulated  in  a  Real-time  Transport 
Protocol  (RTP)  (REC  1889)  datagram.  RTP  is  used  with  other 
protocols  to  provide  transport  for  real-time  data  such  as 
voice  or  video.  The  RTP  header  contains  sequencing,  time 
stamping,  and  content  information.  This  datagram  is 
usually  transported  via  User  Datagram  Protocol  (UDP)  (REC 
768)  .  The  UDP  datagrams  are  then  encapsulated  into 
Internet  Protocol  (IP)  (REC  791)  datagrams  that  are  used  to 
route  the  information  to  the  desired  destination.  At  the 
destination,  each  layer  is  stripped  until  the  voice  data 
stream  can  be  reassembled. 

C.  VOIP  AT  THE  NODE  LEVEL 

Implementing  VoIP  at  the  node  level  is  very  different 
depending  on  which  governing  bodies'  protocols  are  used  by 
the  equipment  manufacturer.  These  different 
implementations  are  not  compatible  with  each  other  so  it  is 
important  to  know  which  is  being  used.  Some  manufacturers 
of  VoIP  equipment  will  include  the  capability  to  interface 
using  protocols  from  either  governing  body  but  this  is  not 
always  the  case.  This  section  describes  the  different  sets 
of  protocols  from  each  governing  body.  A  system  based  on 
the  lETE  recommendations  is  presented  first  followed  by  a 
system  described  using  the  ITU  standards. 
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1.  Internet  Engineering  Taskforce  (IETF) 

The  Internet  Engineering  Task  Force  (IETF)  is  the 
governing  body  responsible  for  recommending  standards  for 
the  Internet.  As  such  the  recommendations  for  VoIP  tend  to 
be  rooted  in  networking  fundamentals.  The  following  is  an 
example  of  a  typical  call  using  terms  from  the  IETF 
framework : 

A  User  Agent  is  the  software  that  interfaces  with  and 
acts  on  behalf  of  the  user.  The  user  agent  uses  the 
Session  Initiation  Protocol  (SIP)  (RFC  2543  found  on  Figure 
3)  to  initiate  a  call.  SIP  is  used  to  establish,  modify, 
or  end  a  VoIP  session.  The  User  Agent  will  use  SIP  to 
contact  either  a  proxy  server  or  a  redirect  server.  The 
Proxy  Server  will  act  on  behalf  of  the  User  Agent  and 
forward  an  address  request  to  the  next  node  while  the 
Redirect  Server  will  send  the  next  node  information  back  to 
the  User  Agent  for  further  requests.  Once  the  address  is 
resolved,  the  User  Agents  negotiate  the  parameters  of  the 
call  in  Session  Description  Protocol  (SDP)  (RFC  2327  found 
on  Figure  3)  messages.  SDP  is  used  by  other  protocols  as  a 
standard  format  to  describe  the  elements  of  a  session  such 
as  which  CODEC  will  be  used.  If  the  call  will  traverse  to 
a  different  type  of  network,  the  Media  Gateway  Controller 
negotiates  the  call  and  acts  to  mediate  between  the  source 
and  destination  User  Agents  during  the  call.  Multi  Gateway 
Control  Protocol  (MGCP)  (RFC  2705  found  on  Figure  3) 
establishes  the  use  of  Media  Gateway  Controllers.  These 
controllers  govern  the  operation  of  various  Media  Gateways. 
Media  Gateways  translate  between  various  types  of  networks 
such  as  the  Telco  Backbone,  a  local  loop,  an  Asynchronous 
Transfer  Mode  (ATM)  network,  or  a  PBX. 
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Figure  3 :  Protocols  related  to  Voice  over  IP  (From 
Miller,  2002) 

2.  International  Telecommunications  Union  (ITU) 

The  International  Telecommunicat ions  Union  (ITU)  is  a 

body  responsible  for  establishing  global  telecommunications 

standards.  The  specifications  from  the  ITU  for  VoIP 

closely  follow  other  telecommunications  standards  and 

specify  the  working  of  VoIP  in  terms  of  signaling.  In 

contrast  to  the  lETF's  collection  of  protocols  that  can  be 

used  for  VoIP,  the  ITU  provides  a  single  specification, 

H.323.  H.323  is  an  overarching  standard  for  "packet  based 
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multimedia  without  QOS".  H.323  incorporates  other 
protocols  such  as  H. 225.0  for  terminal  to  gatekeeper 
signaling  and  H.245  for  Terminal  control.  Figure  4  shows 
the  relationship  between  these  protocols  and  the  transport 
mechanism . 
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Figure  4:  H.323  Protocol  Stack  (After  Black,  2000) 

A  detailed  call  progression  for  systems  using  H.323  is 
beyond  the  scope  of  this  paper.  A  summarized  description 
follows : 

A  user's  equipment  is  called  a  terminal.  Before  a 
call  can  be  placed,  the  terminal  must  register  with  a 
gatekeeper.  If  the  terminal  is  a  part  of  a  data  network, 
the  terminal  performs  the  encoding,  compression,  and 
encapsulation  of  the  voice  sample.  If  the  terminal  is  not 
part  of  a  network,  this  function  is  performed  by  the 
Gateway.  A  Gatekeeper  serves  as  the  overall  controller  of 
the  VoIP  system.  It  controls  access  to  the  network, 
manages  bandwidth,  and  performs  address  resolution.  The 
source  and  destination  Gatekeeper  actually  establish  a 
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call.  If  the  call  will  traverse  a  non-IP  based  network, 
the  Gatekeeper  controls  the  Gateways  that  perform  the 
required  translations.  The  Gatekeeper  uses  the  previously 
mentioned  Media  Gateway  Control  Protocol  (MGCP)  or  its 
replacement.  Media  Gateway  Control  (MEGACO/H . 24 8 )  for 
control  of  all  nodes.  MEGACO/H. 248  is  a  joint  lETE  and  ITU 
standard  based  on  Media  Gateway  Control  Protocol  (MGCP) . 

This  section  shows  VoIP  technology  is  actually 
governed  by  two  different  bodies,  the  lETE  and  the  ITU. 
The  methods  and  equipment  used  by  each  are  different.  The 
differences  are  seen  at  the  node  level  but  ultimately,  both 
accomplish  voice  transmission  over  an  IP  based  network.  No 
matter  which  type  of  system  is  used,  specific  challenges 
must  be  overcome  if  VoIP  is  to  be  successful. 
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IV.  CHALLENGES  OF  VOIP 


For  any  replacement  technology  to  become  widely 
accepted,  the  services  provided  must  be  comparable  with 
those  of  the  current  system.  More  often,  users  demand  even 
more  from  a  new  technology.  In  the  case  of  VoIP,  this 
presents  several  technical  challenges.  This  chapter 
addresses  the  four  main  technical  VoIP  issues  that  should 
be  considered  when  a  network  is  first  engineered.  They  are 
voice  quality,  delay,  jitter,  and  packet  loss. 

A.  VOICE  QUALITY 

Users  have  come  to  expect  high  quality  voice 
communication  using  current  technologies.  For  VoIP  to  be 
successful,  it  must  be  able  to  produce  comparable  quality 
voice  communication.  VoIP  voice  quality  is  primarily 
affected  by  compression  of  the  voice  signal  and  the  type  of 
encoding  used  in  VoIP  applications.  Compression  is 
important  in  trying  to  reap  the  benefits  of  VoIP  because  it 
reduces  the  amount  of  data  transmitted.  The  benefits  of 
compression  come  with  a  price  because  compression  affects 
the  quality  of  the  recovered  voice  signal.  The  Mean 
Opinion  Score  (MOS)  is  a  subjective  scoring  that  rates  the 
quality  of  a  coder/decoder  (CODEC)  under  various  conditions 
such  as  background  noise  and  multiple  encodings.  Figure  5, 
shows  an  averaged  MOS  for  common  CODECs  used  in  VoIP. 
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Figure  5:  Comparison  of  Compression  Techniques  (After 
Caputo,  2000) 

Each  time  a  voice  sample  is  encoded  the  MOS  decreases. 
This  is  important  because  for  each  segment  of  a  network 
that  requires  a  CODEC  translation,  the  resulting  MOS  will 
be  lower.  (Davidson,  2000)  This  will  adversely  affect  the 
quality  of  the  received  voice  signal. 

Silence  Suppression  also  adversely  affects  MOS. 
Silence  Suppression  techniques  are  used  to  save  bandwidth 
by  not  transmitting  during  periods  of  silence.  The  problem 
with  these  techniques  is  that  clipping  of  the  conversation 
can  occur. 

Even  though  compression  and  silence  suppression  reduce 
the  MOS  and  degrade  the  quality  of  the  received  signal, 
they  are  still  used  by  some  VoIP  applications.  Not  all 
VoIP  applications  do  both.  VoIP  can  be  tailored,  by  CODEC 
selection,  to  trade  voice  quality  for  bandwidth  savings  as 
desired . 

B .  DELAY 

Delay  is  the  amount  of  time  it  takes  a  signal  to  be 
digitized,  transferred,  and  then  converted  back  into  an 
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analog  signal  at  the  receiver.  A  delay  of  250ms  or  less  is 
the  generally  accepted  threshold  for  commercial  toll 
quality  service.  Often,  however,  longer  delays  are 
tolerated.  Some  overseas  phone  calls  and  long  distance 
cellular  phone  calls  have  delays  exceeding  250ms. 
Communication  via  satellite  is  still  possible  even  with 
delays  in  excess  of  500ms.  The  sum  of  all  delays  in  the 
system  is  called  the  end-to-end  delay.  End-to-end  delay  is 
generally  referred  to  as  just  the  delay  or  latency  of  the 
system.  There  are  three  types  of  delay  to  consider  when 
discussing  VoIP.  These  are  propagation  delay, 
serialization  delay,  and  handling  delay. 

Propagation  delay  is  the  time  it  takes  for  a  signal  to 
traverse  the  physical  media.  For  a  copper  wire,  this  is 
about  8  microseconds/mile.  For  applications  involving  a 
few  thousand  miles  this  may  not  be  significant  but  if  the 
network  uses  a  High  Earth  Orbiting  satellite,  this  delay  is 
on  the  order  of  500ms  which  is  significant. 

Serialization  delay  is  characterized  by  the  number  of 
bits  that  can  be  transferred  per  second.  This  is  not  to  be 
confused  with  the  data  rate  of  the  media.  This  can  more 
accurately  be  described  as  the  data  rate  of  the  physical 
interface.  This  is  generally  neglected  and  not  an  issue  for 
VoIP  implementation  since  it  is  such  a  small  contribution 
to  the  overall  delay  in  the  system. 

Finally,  handling  delays  incorporate  all  delays  caused 
by  manipulating  the  data.  If  20ms  of  voice  is  packaged 
into  a  single  datagram,  the  handling  delay  is  this  20ms 
plus  the  time  to  actually  encode  the  data.  Additionally 
there  is  a  delay  as  each  piece  of  equipment  handles  the 
information.  Significant  delays  occur  when  data  is  queued. 
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For  most  applications,  handling  delay  is  the  biggest 
contributor  to  the  end-to-end  delay,  but  is  also  the  one 
type  of  delay  best  controlled  through  proper  engineering  of 
the  system. 

C .  JITTER 

Jitter  is  the  variation  in  the  inter-arrival  time 
between  packets.  Jitter  is  important  because  if  not 
accounted  for  properly  it  can  cause  the  decoded  message  to 
sound  choppy.  The  affects  of  jitter  are  usually  corrected 
by  implementing  a  jitter  buffer  that  delays  messages  on  the 
receiving  end  longer  than  the  experienced  jitter.  This 
allows  the  information  to  be  replayed  at  a  constant  rate. 
Implementation  of  the  jitter  buffer  does  contribute  to  the 
delay  but  is  necessary  for  maintaining  voice  quality. 

D .  LOST  PACKETS 

Packet  loss  is  not  unexpected  in  any  network.  This  is 
the  reason  Transmission  Control  Protocol  (TCP)  contains  a 
mechanism  for  the  retransmission  of  missing  packets.  The 
time  that  it  takes  for  a  missing  packet  to  be  retransmitted 
is  unacceptable  in  VoIP.  This  is  the  main  reason  VoIP 
applications  use  the  User  Datagram  Protocol  (UDP) ,  which 
does  NOT  retransmit  lost  packets.  The  loss  of  a  single 
packet  can  be  masked  by  replaying  the  previous  voice 
sample.  This  technique  does  not  work  when  multiple  packets 
are  missing.  When  multiple  packets  are  lost,  the  decoded 
voice  signal  may  contain  a  pause  or  sound  choppy. 
Engineering  a  highly  reliable  network  can  mitigate  the 
number  of  lost  packets. 

These  technical  challenges  are  not  insurmountable 
obstacles  but  rather  items  that  must  be  addressed.  When 
engineering  a  system  for  VoIP,  mechanisms  to  control  voice 
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quality,  delay,  jitter,  and  packet  loss  must  be  included. 
The  next  chapter  will  examine  the  current  Navy  INMARSAT 
communication  architecture.  Later  chapters  will  show  how 
this  architecture  can  benefit  from  the  transition  to  VoIP. 


23 


THIS  PAGE  INTENTIONALLY  LEE!  BLANK 


V. 


THE  NAVY  VOIP  IMPLEMENTATION 


As  previously  discussed,  VoIP  increases  efficient  use 
of  bandwidth  by  converging  voice  and  data  networks.  The 
Navy  currently  uses  circuit  switching  for  voice 
communications  and  the  Automated  Digital  Network  System 
(ADNS)  for  managing  data  communications.  This  chapter  will 
discuss  using  VoIP  to  converge  these  networks.  VoIP  will 
be  implemented  within  the  ADNS.  This  chapter  will  describe 
the  current  ADNS  and  review  some  of  the  VOIP  technical 
considerations  as  they  relate  to  ADNS.  Finally,  two  (2) 
possible  implementation  strategies  are  presented. 

A.  THE  AUTOMATED  DIGITAL  NETWORK  SYSTEM 

To  manage  the  increasingly  important  and  complex  web 
of  bandwidth  limited  communications,  the  Navy  developed  the 
Automated  Digital  Network  System  (ADNS) .  ADNS  is  designed 
to  combine  and  manage  the  multiple  data  communications 
paths  that  include  UHF,  SHF  and  EHF  communications  while  at 
sea  as  well  as  copper  and  fiber  optic  connections  when 
pier-side.  ADNS  provides  continuous  data  connectivity  for 
the  ship.  If  one  communications  path  becomes  inoperative, 
ADNS  is  designed  to  allow  another  path  to  handle  important 
traffic.  Using  this  system,  most  Unit  Level  ships 
communicate  while  underway  via  a  64kbps  INMARSAT  leased 
connection.  This  leased  channel  is  normally  configured  as 
half  for  data  and  the  other  half  for  Plain  Old  Telephone 
System  (POTS)  connectivity.  Figure  6  is  a  simplified  block 
diagram  of  the  ADNS. 
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Figure  6 :  Simplified  Block  Diagram  of  ADNS  (After 
Buddenburg,  2003) 

Figure  6  shows  the  system  is  composed  of  several 
security  enclaves.  These  enclaves  are  merged  with  the 
secret  enclave  at  the  ADNS  router  using  Inline  Network 
Encryption  (INE)  to  form  a  common  off-ship  data  stream. 
The  data  stream  then  travels  through  the  Time  Division 
Multiplexing  (TDM) /MUX  where  it  is  multiplexed  with  the 
circuit  switched  voice  communications  and  sent  via 
satellite  connection  to  shore. 

B.  TECHNICAL  CONSIDERATIONS  TO  THE  VOIP  IMPLEMENTATION 
1 .  Delay 

As  previously  stated,  there  is  a  need  to  manage  delay 

in  a  VoIP  implementation.  Because  INMARSAT  uses  satellites 

in  a  geostationary  orbit,  the  propagation  delay  is 

significant,  commonly  more  than  500ms.  Although  the  250ms 

goal  for  toll  quality  voice  is  no  longer  feasible,  managing 
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'handling  delays'  is  still  important.  The  effective  data 
rate  of  the  VoIP  system  is  closely  tied  to  the  frame  size. 
Selecting  an  appropriate  frame  size  is  actually  an 
optimization  problem.  A  large  frame  size  can  lead  to  a 
high  efficiency  because  the  fixed  overhead  associated  with 
transport  and  encryption  has  less  impact  on  the  effective 
data  rate.  But,  a  large  frame  size  increases  handling 
delays  and  adversely  affects  voice  quality.  The  selection 
of  an  appropriate  frame  size  must  balance  efficiency  needs 
with  voice  quality  desires. 

2 .  Jitter 

Jitter  must  also  be  closely  monitored.  In  a  low 
bandwidth  connection,  such  as  INMARSAT,  increasing  queuing 
delays  for  data  are  likely  to  occur.  This  delay  will 
manifest  as  jitter.  For  an  ADNS  implementation  of  VoIP  to 
succeed,  the  queuing  delay  must  be  controlled.  This  can  be 
accomplished  by  implementing  a  Quality  of  Service  (QOS) 
mechanism  that  provides  priority  handling  for  VoIP  traffic. 
In  the  latest  version  of  the  ADNS,  Class  Based  Weighted 
Fair  Queuing  (CBWFQ)  provides  QoS.  (Barsaleau  &  Tummala, 
2004)  CBWFQ  can  provide  guaranteed  bandwidth  and  expedited 
service  for  the  VoIP  traffic  and  ensure  a  fair  allocation 
of  resources  to  each  ADNS  enclave. 

3.  Packet  Loss 

A  third  factor  to  consider  when  implementing  VoIP  in 
the  ADNS  is  packet  loss.  The  main  contributor  to  packet 
loss  is  Bit  Error  Rate  (BER)  .  The  BER  is  the  probability 
that  an  individual  bit  will  be  corrupted  during 
transmission.  If  a  bit  is  corrupted,  the  packet  is 
discarded  and  considered  lost.  For  a  terrestrial  network, 
BERs  are  usually  less  than  10~^°  and  are  not  often 

considered  a  significant  issue. 
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In  a  Navy  system  that  uses 


RF  transmissions  for  data  transfer,  this  is  not  the  case. 
For  a  typical  INMARSAT  connection,  BERs  in  the  realm  of  10” 
^-10”^  are  common.  As  frame  size  increase,  the  probability 
of  a  lost  packet  increases  as  well.  Additionally,  the 
negative  impact  on  voice  quality  created  by  that  lost  frame 
also  increases.  When  determining  the  frame  size  for  an 
ADNS  VoIP  implementation,  BER  should  be  considered. 

C.  TWO  POSSIBLE  IMPLEMENTATIONS 

1 .  Direct  VoIP  Implementation 

The  Navy  currently  uses  the  secret  network  as  its 
common  ship  to  shore  and  shore  to  ship  routing  network. 
All  traffic  from  the  unclassified  and  SCI  enclaves  are 
encrypted  using  an  IPSec  device,  also  referred  to  as  an 
Inline  Network  Encryption  (INE)  device.  The  encrypted 
traffic  is  then  joined  with  the  secret  data  traffic  in  the 
ADNS  router.  The  INE  currently  used  by  ADNS  is  the 
Taclane.  Eigure  7  depicts  the  current  security 
configuration  of  ADNS  and  shows  were  VoIP  traffic  will  be 
introduced  into  the  network  at  the  UNCLASSIEIED  enclave. 


Ship  to  Ship 
And  Ship  to  Shore 


DWTS  Pt-Pt 
Ship  to  Ship 


SATCOM  Pt-Pt 
Ship  to  Shore 
SHF,  CA  iii 
inmarsat,  etc. 


Figure  7 :  Current  ADNS  Ship  Configuration  (From  Casey, 

2004) 
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2 .  An  Alternative  VoIP  Implementation 

The  impact  of  the  direct  implementation  presented 
above  is  the  addition  of  overhead  to  the  VoIP  traffic  from 
the  INE .  The  INE  adds  a  minimum  of  58  bytes  to  the  IP 
datagram.  This  increases  the  effective  data  rate  required 
for  VoIP  implementation.  Eliminating  the  overhead  of  the 
INE  from  voice  traffic  will  increase  the  efficiency  of  the 
implementation.  Eigure  8  shows  an  alternative 
implementation  called  a  "Black  ADNS  Ship  Configuration" 
(Erom  Casey,  2004). 


Figure  8:  Black  ADNS  Ship  Configuration  (From  Casey, 

2004) 


This  proposed  solution  sends  the  secret  enclave 
through  an  INE.  VoIP  traffic  is  combined  with  the  other 
network  traffic  at  the  ADNS  router.  However,  in  this 
configuration,  the  VoIP  traffic  does  NOT  pass  through  an 
INE.  There  is  no  added  overhead.  This  will  increase  the 
efficiency  of  the  VoIP  implementation. 
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This  chapter  introduced  two  possible  VoIP 
implementations  within  the  Automated  Digital  Network  System 
(ADNS) .  The  thrust  of  this  research  was  to  develop  a  model 
that  simulates  these  two  scenarios.  The  next  chapter 
describes  the  model  development. 
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VI . 


MODEL  DEVELOPMENT 


Simulation  models  are  a  quick  and  efficient  way  to 
narrow  the  field  of  research.  Through  high  level  modeling 
of  a  proposed  network,  quick  feasibility  studies  can  be 
conducted  and  future  work  can  be  scoped.  A  more  detailed 
model  can  help  tune  parameters  or  verify  the  correctness 
and  optimization  of  a  protocol.  All  of  this  can  be 
accomplished  without  procuring  equipment.  Hours  worth  of 
data  can  be  obtained  in  minutes  worth  of  runs. 

When  modeling,  it  is  easy  to  over  analyze  a  problem  in 
an  effort  to  provide  a  high  fidelity  model.  In  order  to 
scope  a  project  and  determine  what  is  important  to  model, 
it  is  necessary  to  first  state  the  problem  as  simply  as 
possible.  The  base  question  to  be  answered  in  this 
research  is:  Is  it  beneficial  to  pursue  the  implementation 
of  VoIP  on  Unit  Level  ships?  Other  questions  will  have  to 
be  answered  before  a  final  conclusion  can  be  reached,  but 
this  question  must  always  be  kept  in  mind.  Once  the 
question  has  been  determined,  a  modeling  tool  must  be 
selected . 

A.  TOOL  SELECTION 

OMNeT++  was  chosen  because  the  author  was  familiar 
with  the  package  and  modification  and  extensibility  of  the 
existing  functionality  are  easy  to  accomplish.  OMNeT++  is 
a  simulation  environment  whose  primary  application  area  is 
the  simulation  of  communications  networks.  It  is  flexible 
enough  to  simulate  IT  systems,  queuing  networks,  hardware 
architectures  and  business  processes  as  well.  Simulation 
components  are  written  in  C++  and  the  modules  are  written 
in  an  easy  to  understand  language  called  NED.  OMNeT++  is 
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easy  to  learn  and  use  and  well  suited  to  this  research 
effort.  Appendix  B  contains  a  complete  listing  of  the 
OMNeT++  code  written  specifically  for  this  research  effort. 

Once  the  simulation  tool  was  selected,  the  next  step 
was  to  develop  the  model.  The  steps  used  in  model 
development  are  described  below. 

B .  MODEL  DEVELOPMENT 

Although  it  is  possible  to  model  every  component  in 
the  ADNS  simplified  block  diagram  (figure  6)  ,  every 
component  was  not  needed  to  answer  the  research  question. 
The  first  step  was  to  determine  which  nodes  and  connections 
were  important  and  to  simplify  the  network  to  only  these 
nodes  and  connections. 

The  last  part  of  the  ADNS  system,  from  the  ADNS  router 
through  the  satellite  link,  was  the  easiest  to  simplify. 
The  first  simplification  was  to  consolidate  the  time  lag 
introduced  by  the  KG' s  and  the  satellite  link  into  a  single 
delay.  Next  the  bandwidth  restrictions  in  the  FCClOO  and 
the  satellite  were  modeled  using  the  most  restrictive 
setting.  The  voice  from  the  FCClOO  was  not  included 
because  it  was  already  accounted  for  in  the  bandwidth 
restrictions.  The  delay  and  data  rate  were  combined  into  a 
single  channel  that  was  modeled  as  a  500ms  delay  and  either 
a  32  kbps  or  64  kbps  data  rate. 

The  ADNS  router  was  modeled  next.  The  ADNS  router 
performs  two  primary  functions  in  the  model.  It  both 
routes  the  incoming  and  outgoing  messages  and  provides  QoS 
for  the  messages  traveling  via  the  INMARSAT  link. 
Separating  these  two  functions  in  our  model  makes  it  easier 
to  examine  various  QoS  mechanisms  at  a  later  time.  Because 
of  this  separation,  the  OMNeT++  IPSuite  standard  router  was 
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used  as  the  router  component  and  a  new  component  called  a 
WRED  Box  was  created. 

The  WRED  Box  was  loosely  based  on  the  description  of 
Weighted  Random  Early  Drop  (WRED)  and  Class  Based  Weighted 
Eair  Queuing  (CBWEQ)  found  in  (Barceleau,  2004) .  The 
component  actually  used  is  a  scaled  down  version  that 
adequately  represents  the  configurations  needed  by  this 
research.  The  WRED  Box  queues  the  incoming  messages  into 
either  a  High  Priority  Queue  (HPQ)  or  a  Low  Priority 
Queue  (LPQ)  .  Those  messages  with  a  Differentiated  Services 
Code  Point  (DSCP)  marker  of  46  were  placed  into  the  HPQ. 
As  long  as  the  HPQ  contains  items  but  has  not  yet  reached 
its  reserved  allotment  of  bandwidth,  the  model  services  the 
HPQ.  The  LPQ  is  serviced  when  the  HPQ  is  empty  or  exceeds 
its  reserved  allotment.  The  WRED  algorithm  for  controlling 
queue  depth  is  implemented  on  both  queues.  Because 

throughput  was  already  calculated  for  the  HPQ,  the 
measurements  for  system  throughput  were  taken  at  this  point 
for  all  types  of  traffic.  The  code  written  to  model  this 
component  can  be  found  in  Appendix  B. 

The  INE  was  modeled  next.  It  was  modeled  as  a 

separate  element  to  provide  flexibility  in  the  model. 
Messages  that  are  encrypted  can  be  connected  through  this 
node  to  incur  the  INE  overhead;  those  that  are  not,  bypass 
it.  The  INE  was  created  based  on  the  equation  found  in 
(Hucke,  et .  all,  2003).  Rather  than  actually  encapsulating 
the  message  as  described  in  (Hucke,  2003) ,  the  IP  Header 
field  length  was  modified  to  save  on  computing  resources 

when  running  the  simulation.  The  code  written  to  model 

this  component  can  be  found  in  Appendix  B. 
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The  voice  traffic  was  modeled  next.  A  client  was 
needed  that  periodically  sends  a  burst  of  information  and 
then  waits  for  a  reply.  The  reply  was  modeled  after  an 
actual  conversation  where  the  listener  responds  after  a 
reasonable  period  of  inactivity. 

The  original  plan  was  to  create  a  voice  client  based 
on  an  available  RTP  implementation.  Further  research 
showed  the  only  impact  RTP  had  on  the  model  was  the 
addition  of  8  bytes  to  the  packet  size.  At  this  point, 
instead  of  creating  a  voice  client  based  on  the  RTP 
implementation,  the  OMNeT++  IPSuite  UDP  Host  was  modified 
to  create  a  VoIP  Host.  The  client  application  modeled  the 
voice  traffic  in  the  following  manner:  Based  on  the  CODEC 
rate,  frame  size,  and  reply  length,  a  number  of  messages 
are  sent,  modeling  a  voice  burst.  An  internal  timeout  was 
then  used  to  initiate  a  reply.  The  timeout  was  reset  with 
the  arrival  of  each  message  from  the  transmitting  end.  The 
length  of  each  message  is  increased  by  8  bytes  to  account 
for  the  RTP  overhead.  A  second  timeout  was  added  to 
control  the  call  cycle.  This  simulates  a  normal  phone 
being  on  and  off  hook.  The  server  side  was  merged  into  the 
client  to  simplify  the  reply  mechanism.  The  code  written 
to  model  this  component  can  be  found  in  Appendix  B. 

Once  the  VoIP  client  was  written,  an  appropriate  CODEC 
had  to  be  selected.  The  model  was  built  on  the  premise 
that  the  CODEC  data  rate  and  frame  size  were  the  driving 
factors  in  performance.  The  G.723r53  was  selected  because 
it  requires  the  lowest  data  rate.  Eor  the  STUIII  calls, 
however,  other  factors  come  into  play.  The  STUIII  was 
designed  for  data  over  voice  and  does  not  perform  well  with 
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the  lower  data  rate  CODECs.  From  results  in  (Hucke,  2003), 
the  G.726rl6  was  selected  as  the  CODEC  used  for  STU  capable 
conversations . 

The  background  traffic  was  modeled  next.  A  UDP  client 
was  selected  because  a  flow  of  data  could  be  shaped  to 
provide  constant  loading  to  the  system.  Initially,  using  a 
TCP  client  and  server  was  considered.  However,  further 
research  showed  that  managing  the  proper  number  of  clients 
to  create  the  desired  loading  would  be  difficult.  The 
purpose  of  the  model  is  not  to  measure  the  amount  of 
traffic  passed  through  the  network  but  instead  to  measure 
the  change  in  the  amount.  Therefore,  the  model  could  be 
simplified  by  combining  the  clients  from  the  three 
enclaves.  It  is  the  relative  change  in  the  aggregate 
traffic  that  is  of  interest  to  this  research.  If  further 
work  is  contemplated  on  QoS  mechanisms,  it  may  be  required 
to  separate  the  types  of  traffic  and  identify  the  source 
enclave  of  each. 

The  standard  UDP  client  was  considered,  but  it  did  not 
give  enough  control  over  the  amount  of  data  that  was  being 
sent,  therefore  this  client  was  also  rewritten.  The 
Traffic  UDP  Host  was  created  to  constantly  transmit  packets 
based  on  the  desired  data  rate  and  message  size.  On  the 
receiving  side  of  the  host,  the  message  is  dropped  once  the 
desired  metrics  are  recorded.  The  code  written  to  model 
this  component  can  be  found  in  Appendix  B. 

This  completed  the  modeling  of  the  components  that 
make  up  the  overall  VoIP  model.  Before  the  overall  model 
could  be  run,  two  major  questions  had  to  be  answered. 
First,  what  is  the  optimal  frame  size?  Second,  do  TCP 
congestion  control  methods  preclude  the  use  of  UDP  data 
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streams  as  an  appropriate  abstraction  for  accurately 
modeling  composite  network  traffic?  The  following  section 
describes  how  these  questions  were  answered. 

C .  INTERMEDIATE  MODELS 

1 .  Frame  Size 

In  order  to  determine  the  optimal  frame  size,  two 
network  simulations  were  built  using  components  already 
modeled.  The  code  written  creating  this  simulated  network 
can  be  found  in  Appendix  B.  The  results  of  these 
simulations  were  used  to  determine  the  effects  of  various 
frame  sizes  on  the  required  effective  data  rate  for 
different  CODECs  when  the  IP  and  INE  overheads  are  applied. 
Eigure  9  shows  the  network  used  to  test  this  CODEC 
efficiency  at  various  frame  sizes  with  an  INE. 


Figure  9 :  VoIP  network  with  INEs 


Runs  were  conducted 

at 

16 

kbps  and 

at  5.3 

kbps  with 

frame  size  varying 

from 

10 

to 

500  ms. 

The  network  was 

modified  to  remove 

the 

INE 

and  the  runs  were 

repeated . 

Measurements  for  throughput  were  taken  at  the  node  labeled 
wredl . 

Eigure  10  shows  a  graphical  representation  of  the 
results.  It  plots  the  required  effective  data  rate  verses 
frame  size  for  the  four  previously  described  runs.  The 
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lower  the  data  rate  required,  the  more  effectively  the 
CODEC  performs  at  that  frame  size. 


- 5.3kbps 

I - 16kbps 

, - 5.3kbps  (w/  INE) 

- 16kbps  (w/  INE) 


Figure  10:  Effect  of  frame  size  on  CODEC 

performance 

From  figure  10,  we  see  the  larger  the  frame  size  the 
more  effective  the  CODEC  performance  as  would  be  expected. 
As  frame  size  increases  above  approximately  140  ms  the 
improvement  is  marginal.  Taking  into  account  the  earlier 
discussion  of  handling  delay,  the  140  ms  frame  size  is  the 
optimized  solution  between  efficiency  and  voice  quality. 
The  jagged  steps  in  the  curves  that  correspond  to  the 
networks  with  an  INE  result  from  the  padding  introduced  by 
the  Taclane.  This  padding  is  used  to  obtain  a  48-byte 
increment  needed  in  the  encryption  of  the  packet  and 
implies  that  the  best  performance  will  be  achieved  where 
the  packet  size  is  near  a  multiple  of  48  bytes.  The  140  ms 
frame  size  fits  this  requirement  as  well. 
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These  results  are  based  upon  a  generic  CODEC.  Vendor 
specific  implementations  may  add  look  ahead  or  other 
mechanisms  that  increase  quality  of  service  but  also  change 
the  effective  CODEC  data  rate.  Therefore,  these  results 
should  be  modified  when  considering  optimal  settings  for 
actual  CODEC  use. 

2 .  Impact  of  TCP  Congestion  Control 

After  initial  design  considerations  were  complete,  a 
conversation  with  Mr.  Ed  Hucke  from  SPAWAR  PMW  17  9,  the 
engineers  of  ADNS,  made  us  question  the  decision  to  model 
the  network  traffic  as  UDP  packets.  Mr.  Hucke  stated  a 
concern  that  the  TCP  Slow  Start  congestion  control 
mechanism  may  reduce  the  amount  of  traffic  that  could  be 
transmitted  in  the  periods  without  voice  transmissions  due 
to  a  lag  in  resumption  of  traffic  to  fill  the  available 
bandwidth.  (Schilke,  1997)  confirms  this  could  be  an 
issue . 

To  test  the  theory,  the  standard  TCP  client  was 
modified  to  collect  'goodput'  .  Goodput  is  the  rate  at 
which  unique  data  arrives  at  the  client.  The  network 
simulation  shown  in  Eigure  11,  was  designed  to  test  the 
effects  of  the  Slow  Start  algorithm  on  changes  to  the 
bandwidth  available  for  low  priority  messages.  The  code 
written  creating  this  simulated  network  can  be  found  in 
Appendix  B.  The  results  of  this  simulation  would  determine 
if  UDP  accurately  models  aggregate  network  traffic  changes. 
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Figure  11:  TCP  Client  Network 

The  network  was  configured  for  a  variable  number  of 
TCP  clients  with  matching  servers  and  three  VoIP  Clients. 
A  heavy  load,  medium  load,  and  light  load  were  set  in  the 
configuration  by  using  18  clients,  3  clients,  and  1  client 
respectively.  After  each  run,  the  amount  of  data  received 
from  each  client  was  combined  in  an  Excel  spreadsheet.  The 
data  was  sorted  by  timestamp  and  the  amount  of  data 
received  by  a  client  was  divided  by  the  time  difference 
between  this  timestamp  and  the  previous  timestamp.  This 
calculation  provided  the  network  goodput. 

Figure  12  shows  graphical  results  of  the  run  under 
heavy  load.  It  plots  the  goodput  as  a  data  rate  verses 
time.  Periods  where  congestion  control  effects  are 

potentially  affecting  the  network  traffics  ability  to 


39 


respond  to  cessation  of  voice  transmissions  would  appear 
periods  of  reduced  goodput  occurring  in  the  absence 
voice  transmissions. 


as 


of 


Figure  12:  Data  Rate  for  network  with  18  Clients 

As  expected  for  the  heavy  load,  shown  in  Figure  12, 
the  amount  of  data  queued  and  the  number  of  clients 
receiving  data  tended  to  dampen  most  congestion  control 
effects.  There  was  no  evidence  that  the  slow  start 

protocol  would  cause  a  problem  with  modeling  the  traffic  as 
UDP  packets. 

When  the  runs  were  repeated  at  a  medium  and  light 
load,  the  number  of  areas  where  congestion  control  was 
potentially  affecting  the  ability  to  model  network  traffic 
using  UDP  increased.  It  is  not  as  clear,  however,  if  these 
are  slow  start  effects  after  the  cessation  of  voice 
transmissions.  Figure  13  shows  that  with  three  clients, 
some  of  the  periods  without  data  being  received  by  a  client 
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have  extended.  If  this  was  an  issue  that  affects  the  use 
of  modeling  as  UDP,  these  periods  would  consistently  appear 
at  the  end  of  each  voice  transmission.  Figure  13  clearly 
shows  this  is  not  the  case.  Therefore,  it  can  be  assumed 
UDP  will  still  accurately  model  the  network  traffic  in  this 
scenario . 
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Figure  13:  Data  Rate  for  Network  with  3  Clients 

Figure  14  shows  the  graphical  results  of  modeling  the 
network  with  a  light  load  of  one  client.  Once  again, 
extended  periods  with  reduced  goodput  are  present.  Again, 
the  lack  of  consistency  in  location  and  duration  can  only 
lead  to  the  conclusion  that  these  periods  are  not  affecting 
transitions  from  voice  transmissions. 
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Figure  14 :  Data  Rate  for  Network  with  1  Client 


To  further  ensure  that  TCP  data  traffic  can  be  modeled 
as  a  UDP  data  flow,  the  goodput  between  voice  transmissions 
for  each  case  was  compared  with  comparable  time  periods  on 
a  simulation  run  with  zero  voice  clients.  The  data 
received  on  this  final  run  was  within  3.5%  of  the  data  in 
each  of  the  previous  simulations,  further  showing  that  our 
decision  to  model  using  UDP  traffic  is  valid. 

Now  that  the  components  have  been  modeled,  the  optimal 
frame  size  determined,  and  the  use  of  a  UDP  Host  for 
Traffic  verified,  the  overall  models  testing  the  two 
different  VoIP  implementations  were  built.  The  code 
written  creating  this  simulated  network  can  be  found  in 
Appendix  B.  The  network  simulations  were  configured  with  a 
UDP  Traffic  Client  and  a  variable  number  of  VoIP  Clients  as 
shown  in  Figure  15. 
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Figure  15 :  Network  for  Determining  VoIP  Transition 
Efficiency 

Each  set  of  runs  varied  the  call  cycle  while  keeping 
the  number  and  configuration  of  the  clients  the  same. 
Detailed  results,  conclusions,  and  future  work  are 
presented  in  the  next  chapter. 
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VII.  RESULTS  AND  CONCLUSIONS 


Is  it  beneficial  to  pursue  the  implementation  of  VoIP 
on  Unit  Level  ships?  To  answer  this  question  the  model 
described  in  the  previous  chapter  was  run  varying  the  call 
cycle  while  keeping  the  number  and  configuration  of  the 
clients  the  same.  The  simulated  network  was  modified  to 
investigate  various  potential  implementation  strategies 
described  in  Chapter  V.  Below  are  the  results  of  those 
simulations . 

A.  DIRECT  IMPLEMENTATION  OF  VOIP 

The  direct  VoIP  implementation  was  simulated  using 
varying  numbers  of  VoIP  clients  that  sent  data  through  an 
INE .  Figure  16  shows  graphical  results  obtained  from  the 
direct  implementation  simulation  model. 
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Figure  16:  Effects  of  call  cycle  on  VoIP 

Implementation 
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Figure  16  plots  percent  change  in  goodput  compared  to 
a  baseline  of  32k  data  verses  the  call  cycle  percentage.  A 
gain  is  realized  when  the  percent  change  in  goodput  is 
greater  than  zero.  The  ideal  case  would  be  where  the 
percent  change  in  goodput  is  greater  than  zero  through  100% 
call  cycle.  The  different  runs  represent  different 
possible  combination  of  POTS  and  STU  lines  in  use 
simultaneously.  Run  configurations  do  not  include 
configurations  that  will  exceed  the  total  available 
bandwidth . 

Figure  16  shows  an  increase  in  the  throughput  for  data 
traffic  over  the  current  ADNS  configuration  for  up  to  a  72% 
call  cycle  when  implementing  VoIP  using  two  (2)  POTS  lines 
and  one  (1)  STU  line.  With  silence  suppression  enabled  a 
throughput  gain  is  seen  through  close  to  a  100%  call  cycle. 
Another  benefit  of  the  transition  to  VoIP  shown  by  the 
results  of  this  simulation  is  the  ability  to  have  more  POTS 
lines  than  are  currently  available.  With  silence 
suppression  enabled,  six  (6)  concurrent  POTS  calls  were 
possible  at  near  100%  call  cycle  before  a  decrease  in 
performance  is  seen  compared  to  current  throughput  levels. 

The  current  ADNS  configuration  allows  for  up  to  two 
(2)  POTS  and  two  (2)  STUs  to  be  operated  simultaneously. 
The  Voip  implementation  simulated  above  cannot  support  this 
configuration  and  is  limited  to  two  (2)  POTS  and  one  (1) 
STU  or  two  (2)  STUs.  This  limitation  comes  from  the  64 
kbps  bandwidth  limitation  of  the  currently  fielded  INMARSAT 
configuration . 

The  direct  implementation  model  was  modified  to  use  a 
potential  INMARSAT  upgrade  to  increase  bandwidth  to  128 
kbps,  which  is  commercially  available.  Figure  17  shows  the 
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ability  for  a  VoIP  implementation  under  these  conditions  to 
support  up  to  five  (5)  STU  lines. 
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- 2  POTS 

- 1  STU 

- 3  STU 

- 4  STU 

5  STU 


Figure  17:  Upgraded  128K  INMARSAT 


B.  ALTERNATIVE  VOIP  IMPLEMENTATION 


The 

overhead 

caused 

by  the  INE  can 

be  eliminated 

by 

transitioning 

to 

Black 

Voice  routing 

as  discussed 

in 

Chapter 

V. 

The 

direct 

network  model 

was  modified 

by 

removing 

the 

INE 

module 

associated  with 

each  VoIP  Client. 

Figure  18  shows  the  results  of  the  simulations  run  under 
these  conditions.  This  configuration  can  support  two  (2) 
POTS  and  two  (2)  STU  lines  without  upgrading  the  INMARSAT 
equipment . 
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' - 32K  voice 

^ - 1  STU 

'  2  POTS 

1  POTS  1  STU 
- 2  POTS  1  STU 

. - 2  POTS  1  STU  w/ Silence  Suppression 

' - 2  POTS  2  STU  w/  Silence  Suppression 


Figure  18:  Black  Voice  Routing 

C.  CONCLUSIONS 

This  investigation  has  shown  the  benefit  of  converging 
the  voice  and  data  networks  for  unit  level  ships.  The 
Center  for  Naval  Analysis  documented  the  POTS  usage  for  two 
battle  groups  during  their  JTFX's.  In  their  letter  CME 
D0008489.A1  of  June  2003,  the  authors  stated  that  POTS 
usage  for  the  18  ships  using  INMARSAT  channels  was  8.1 
percent.  (Hucke,  2003)  Using  an  8%  call  cycle  as  a  point 
of  reference,  we  see  approximately  an  85%  increase  in 
bandwidth  available  for  all  configurations.  In  order  to 
realize  these  gains  it  is  not  necessary  to  develop  a  CODEC 
specifically  for  the  STU  line,  it  is  not  necessary  to 
transition  to  a  Black  Routing  paradigm,  nor  upgrade  the 
INMARSAT  connection  to  128kbps.  This  does  not  mean  that 
any  of  these  endeavors  should  be  abandoned  since  all  will 
lead  to  increases  in  performance  that  will  most  likely  be 
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required  in  the  future.  As  the  Navy  becomes  more  NET¬ 
CENTRIC  WAREARE  oriented,  additional  capacity  will  be 
needed.  Implementing  VoIP  and  taking  advantage  of  the 
additional  options  is  one  way  to  meet  this  future  need. 

D .  FUTURE  WORK 

This  is  not  the  end  of  development  for  this  model.  In 
its  current  state,  this  research  has  shown  the  model  is 
able  to  provide  a  quick  feasibility  study.  With  a 

refinement  of  several  components,  however,  it  could  be  used 
to  decide  which  QoS  protocols  show  the  greatest  potential 
benefit  and  where  in  the  network  they  are  best  utilized. 

Although  it  was  appropriate  to  model  the  background 
traffic  as  a  single  UDP  stream  in  this  research  effort, 
many  future  investigations  may  need  greater  fidelity.  When 
the  stable  release  of  IPSuite  is  available,  the  model 
should  be  transitioned  and  a  goodput  analysis  method 
developed  for  TCP. 

A  fleet  demonstration  of  the  direct  implementation  for 
VoIP  is  currently  scheduled  for  the  summer  of  2004. 
Results  from  that  demonstration  should  be  used  to  refine 
the  model  for  future  testing. 

A  more  efficient  means  of  achieving  secure  voice 
communications  is  needed  in  the  form  of  a  native  VoIP 
device  that  can  take  advantage  of  silence  suppression  and 
also  use  lower  data  rate  CODECs. 
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APPENDIX  A.  GLOSSARY 


Analog-to-digital  Converter  (ADC)  -  accepts  an  analog 
input-a  voltage  or  a  current-and  converts  it  to  a  digital 
value  that  can  be  read  by  a  microprocessor. 

Asynchronous  Transfer  Mode  (ATM)  -  a  network  technology 
that  is  based  on  transferring  information  in  cells  of  fixed 
size.  It  well  suited  for  converged  networks  because  it 
creates  a  channel  at  the  beginning  of  a  data  transfer 
session,  allocating  a  fixed  amount  of  resources  to  that 
session . 

Automated  Digital  Network  System  (ADNS)  -  a  system  designed 
to  combine  and  manage  the  multiple  communications  paths  to 
include  UHF,  SHF  and  EHF  communications  as  well  as  copper 
and  optical  pier  side  connections  to  provide  ships  force 
continuous  data  connectivity  for  high  priority  information. 

Automatic  Digital  Network  (AUTODIN)  -  a  legacy 
communications  system  for  ensuring  the  delivery  of  message 
based  communications  throughout  the  Department  of  Defense. 
For  most  purposes  it  has  been  replaced  by  DMS . 

Bandwidth  -  traditionally  the  difference  between  the  upper 
and  lower  frequencies  of  a  transmission  band.  Recently  it 
has  also  come  to  mean  the  amount  of  data  that  can  be  passed 
along  a  communications  channel  in  a  given  period  of  time 
measured  in  bits  per  second  (bps) . 

Bit  Error  Rate  (BER)  -  the  rate  at  which  data  is  corrupted 
expressed  as  a  percentage. 

Centrex  Line  -  a  service  purchased  from  the  local  exchange 
carrier  that  groups  phone  lines  into  a  closed  user  group 
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(CUG)  .  This  provides  additional  services  such  as  call 
transfer  and  call  groups  without  the  purchase  of  a  PBX. 

Class  Based  Weighted  Fair  Queuing  (CBWFQ)  -  provides 
Quality  of  Service  (QoS)  by  separating  traffic  into  queues 
based  upon  a  differentiated  Services  Code  Point  (DSCP)  and 
then  allocating  each  queue  a  share  of  the  bandwidth. 

Closed  User  Group  (CUG)  -  a  grouping  of  business  phone 
lines  that  allows  the  phone  company  to  provide  PBX  services 
from  their  office. 

CODEC  (coder /decoder)  -  a  schema  for  encoding  or  decoding 
information  from  an  analog  to  digital  or  digital  to  analog 
form. 

Convergence  -  the  combining  of  multiple  networks  such  as 
voice  data  and  video  into  one  network. 

Datagram  -  a  self-contained,  independent  entity  of  data 
carrying  sufficient  information  to  be  routed  from  the 
source  to  the  destination  computer  without  reliance  on 
earlier  exchanges  between  this  source  and  destination 
computer  and  the  transporting  network. 

Defense  Message  System  (DMS)  -  a  system  based  upon  email 
standards  to  deliver  message  based  communications 
throughout  the  Department  of  Defense.  It  was  designed  to 
replace  AUTODIN. 

Delay  -  in  VoIP  it  is  the  time  it  takes  for  speech  to 
transmit  from  the  speakers  mouth  to  the  listeners  ear. 

Differentiated  Service  (DiffServ)  -  uses  a  code  in  the 
Type-of-Service  (TOS)  field  of  the  IP  header  to  determine 
priority  handling. 
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Digital-to-analog  Converter  (DAC)  -  accepts  a  digital  input 
and  converts  it  to  a  voltage  or  current  output. 

Enhanced  911  -  a  safety  related  service  that  associates 

location  information  with  an  emergency  call.  Because  the 
information  comes  from  the  phone  company,  systems  such  as  a 
traditional  or  VoIP  PBX  must  have  a  mechanism  to  provide 
this  information. 

Extremely-high  Frequency  (EHF)  -  the  frequency  spectrum 
from  30  -  300  GHz  and  is  often  used  for  military  satellite 
communications . 

FCClOO  -  a  Time  Division  Multiplexing  (TDM) /  Multiplexer 
(MUX)  used  in  the  ADNS  system. 

Gatekeeper  -  used  in  VoIP  to  control  access  to  the  network, 
manage  bandwidth,  and  serve  as  the  address  resolution 

component . 

Gateway  -  provides  the  translation  functions  for  the  voice 
/  data  conversions. 

H.323  -  an  ITU-T  standard  that  offers  audio,  video  and  data 
communications  across  packet-based  network  infrastructures. 
H.323  provides  standards  for  encoding,  bandwidth 

management,  admission  control,  address  translation,  call 
control  and  management,  and  links  to  external  networks.  The 
H.323  protocol  stack  comprises  a  set  of  protocols  that  ride 
on  TCP/IP  and  UDP/IP,  where  TCP  is  used  for  call  setup  and 
control,  while  UDP  is  used  for  data  transmission  and 
reception . 

Inline  Network  Encryption  (INE)  -  an  device  to  provide 

payload  encryption  on  a  packet  by  packet  basis  but  leave 

the  IP  header  information  in  plain  text.  The  device  that 

is  currently  in  use  for  ADNS  is  the  KG-194  TACLANE . 
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IP  Security  (IPSec)  -  A  protocol  that  provides  security  for 
transmission  of  sensitive  information  over  unprotected 
networks  such  as  the  Internet. 


Integrated  Services 

Digital  Network  (ISDN) 

a  set 

of 

communications 

protocols 

that 

specify  the 

carrying 

of 

voice,  video. 

and 

data 

over 

a  single 

wire  that 

is 

eventually  supposed  to  replace  POTS. 

Jitter  -  the  variation  in  delay  between  packets. 

Key  System  -  a  business  telephone  system  that  generally  is 
cheaper  than  a  PBX  but  also  contains  fewer  features. 
Generally  suited  for  smaller  offices. 

Latency  -  see  delay. 

Mean  Opinion  Score  (MOS)  -  a  subjective  scoring  system  for 
rating  the  quality  of  voice  communications.  Obtained  by 
having  a  number  of  people  listen  to  various  voice 
transmissions  and  averaging  their  ratings  of  between  1 
(worst)  and  5. 

Media  Gateway  Control  (MEGACO/H . 248)  -  a  standard  developed 

jointly  by  the  IETF  and  ITU  to  recommend  controls  for 
gateways  between  networks  . 

Multi  Gateway  Control  Protocol  (MGCP)  -  an  IETF  standard  to 
recommend  controls  for  gateways  between  networks. 

Multi-level  Precedence  and  Preemption  (MLPP)  -  a  priority 
scheme  in  military  communications  that  give  priority  to 
certain  calls  and  specifies  timeframes  for  handling  those 
calls . 

Multipoint  Control  Unit  (MCU)  -  connects  three  or  more 
terminals  in  a  "conference  call". 

Packet  -  a  generic  term  used  to  describe  a  unit  of  data. 
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Plain  Old  Telephone  System  (POTS)  -  a  term  used  to  describe 
the  traditional,  analog  based,  telephone  system. 

Private  Branch  Exchange  (PBX)  -  a  business  telephone  system 
that  allows  the  business  complete  control  over  its 
configuration . 

Public  Switched  Telephone  Network  (PSTN)  -  the  collection 
of  interconnected  systems  operated  by  the  various  telephone 
companies  and  administrations  around  the  world. 

Quality  of  Service  (QoS)  -  a  networking  term  that  specifies 
a  guaranteed  throughput  level. 

Radio  Frequency  (RF)  -  a  frequency  in  the  range  within 
which  radio  waves  may  be  transmitted,  from  about  3 
kilohertz  to  about  300,000  megahertz. 

Real-Time  Transport  Protocol  (RTP)  -  provides  real-time 
delivery  of  data,  in  particular  voice  traffic.  RTP  is 
typically  built  on  UDP  but  includes  a  sequencing  system  to 
detect  missing  packets,  as  well  as  information  regarding 
the  payload  type  including  the  audio  and  video  encoding 
used . 

Real-Time  Transport  Control  Protocol  (RTCP)  -  provides  a 
means  to  exchange  quality  of  service  information  between 
nodes  using  RTP. 

Secure  Telephone  Equipment  (STE)  -  the  replacement  for  the 
STU-III . 

Secure  Telephone  Unit  -  Third  Generation  (STU-III)  -  a 

device  designed  to  enable  secure  voice  communications  over 
an  unsecure  voice  network. 

Server  -  in  VoIP  this  is  a  general  term  for  the  Gatekeepers 
and  Gateways . 
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Session  Description  Protocol  (SDP)  -  used  by  other 
protocols  as  a  standard  format  to  describe  a  session. 

Session  Initiation  Protocol  (SIP)  -  considered  as  the 
lETF's  replacement  for  H.323,  and  is  a  text-based  signaling 
protocol  sent  over  TCP  or  UDP . 

Silence  Suppression  -  a  method  of  conserving  bandwidth  in  a 
VoIP  call  by  not  encoding  and  sending  voice  packets  during 
periods  of  silence. 

Super-high  Frequency  (SHF)  -  the  radio  frequencies  between 
3-30  GHz.  Well  suited  for  satellite  communication,  it  is 
the  band  in  which  INMARSAT  operates. 

Tie-line  -  a  communications  link  between  two  PBX's. 

Time  Division  Multiplex  (TDM)  -  a  type  of  multiplexing  that 
assigns  each  voice  or  data  stream  it  own  timeslot. 

Transmission  Control  Protocol  (TCP)  -  a  connection-oriented 
protocol  that  provides  guaranteed  delivery  of  its  payload. 

Ultra-high  Frequency  (UHF) 

Unit  Level  Ship  -  used  to  contrast  with  a  force  level  ship 
(LHA/LHD  or  CV/CVN) .  In  this  paper  it  generally  refers  to 
a  DDG  or  CG. 

User  Agent  -  the  software  that  interfaces  with  and  acts  on 
behalf  of  the  user.  Sometimes  referred  to  as  a  terminal. 

User  Datagram  Protocol  (UDP)  -  a  connectionless  protocol 
that  does  not  provide  guaranteed  delivery. 

Virtual  Private  Network  (VPN)  -  a  network  designed  for 
private  information  created  using  a  public  network  to 
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connect  the  nodes.  Encryption  is  usually  employed  to 
ensure  that  only  authorized  users  have  access  to  the 
private  network. 

Voice  Activity  Detection  (VAD)  -  see  silence  suppression. 

Voice  over  Internet  Protocol  (VoIP)  -  the  transmission  of 
voice  over  an  IP  based  network. 

Weighted  Random  Early  Drop  (WRED)  -  a  congestion  avoidance 
mechanism  that  drops  packets  before  congestion  occurs, 
based  upon  precedence.  Lower  priority  packets  are  more 
likely  to  be  dropped  in  order  to  reduce  congestion  and 
avoid  having  to  drop  higher  priority  packets. 
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APPENDIX  B.  SIMULATION  CODE 


The  following  simulations  were  written  to  run  using 
Omnetpp-3 . 0a3  and  IPSuite-20040322  which  can  be  obtained 
from  www.omnetpp.org.  Later  versions  of  the  software 
change  the  mechanisms  for  creating  and  sending  messages  and 
will  require  modifications  to  this  code.  This  appendix 
begins  with  changes  that  were  made  to  the  IPSuite  source 
code  to  fix  a  few  bugs  and  to  allow  for  data  collection  in 
the  TCP  Client  Application.  The  second  section  provides 
the  source  for  the  basic  components  followed  by  the  last 
section  with  the  source  for  the  networks  used  for  analysis. 
A.  CHANGES  TO  IPSUITE  SOURCE 

IPSuite-2  004  0322 \Applications\TCPApp\procserver . cc 
Line  110 
Change 

msg  =  receive (appl_timeout) ; 

To 

goto  broken; / /application  terminates  connection 

Fixes  -  Problem  that  the  client  will  continue  to  wait 
if  the  server  terminates  connection  due  to  a  timeout.  This 
fix  sends  the  application  into  existing  code  for  handling  a 
broken  connection. 


Line  178 
Change 

msg  =  receive (appl_timeout) ; 
To 
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goto  broken; / /application  terminates  connection 

Fixes  -  Problem  that  the  client  will  continue  to  wait 
if  the  server  terminates  connection  due  to  a  timeout.  This 
fix  sends  the  application  into  existing  code  for  handling  a 
broken  connection. 


Line  217 

Change 

msg  =  receive (appl_timeout) ; 

To 

goto  broken; / /application  terminates  connection 

Fixes  -  Problem  that  the  client  will  continue  to  wait 
if  the  server  terminates  connection  due  to  a  timeout.  This 
fix  sends  the  application  into  existing  code  for  handling  a 
broken  connection. 


IPSuite-2  0  04  0322 \Applicat ions\TCPApp\TCPClient . cc 
Line  293 
Inserted 

//added  to  fix  prob  with  close 

abort  =  new  cMessage ( "TCP_ABORT" ,  TCP_C_ABORT); 
abort->addPar ( " src_port " )  =  local_port; 
abort->addPar ( " src_addr " )  =  local_addr; 
abort->addPar ( "dest_port " )  =  rem_port; 
abort->addPar ( "dest_addr " )  =  rem_addr; 
abort->addPar ( "tcp_conn_id" )  =  tcp_conn_id; 
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//no  data  bits  to  send 


abort->setLength  (0) ; 

//no  data  packets  to  receive 
abort->addPar ( "rec_pks" )  =  0; 

//make  delay  checking  possible 
abort->setTimestamp ( ) ; 

//send  "receive"  to  "TcpModule" 
send (abort,  "out"); 

Fixes  -  TCP  module  waits  for  the  client  sends  a  close 
message  to  the  client  only  once  and  then  waits  for  a  reply. 
For  large  messages,  the  client  is  still  processing  its 
queues  and  does  not  send  the  reply  expected.  This  fix  will 
use  the  existing  abort  mechanism  to  continue  the  process  of 
closing  the  connection. 


IPSuite-2  0  04  0322 \Nodes\ IPSuite\TCPUpperLayers . ned 
Line  63-64 
Change 

/ /message_length  =  input  (8000,  Number  of  bits  to 
be  received:  " ) ; 

message_length  =  8000; 

To 

message_length  =  input  (8000,  "Number  of  bits  to 
be  received:  "); 

/ /message_length  =  8000; 
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Fixes  -  This  change  allows  the  message  length  to  be 
specified  at  run  time. 

IPSuite-20040322\Transport\TCP\tcpmodule . cc 
Line  84 
Add 

cOutVector  *goodput;  //jak  for  recording  goodput 

cOutVector  *avg_goodput ;  //jak  for  recording 
goodput 

cOutVector  *rec_bits; // jak  for  recording  goodput 

Fixes  -  Adds  the  vectors  needed  to  record  goodput 
calculations . 

Line  92 
Add 

//jak  for  goodput  calculations 

cQueue  bw_msg_q;  //store  messages  for  goodput 

calcs 

simtime_t  span;  //length  of  time  between  messages 
for  goodput  calculation 

double  bits;  //length  of  all  msgs  in  bw_msg_q 

Fixes  -  Variables  needed  to  calculate  goodput. 

Line  191 
Add 

~TcpModule  ( ) ; 
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Fixes  -  When  closing  OMNeT  or  rebuilding  a  network, 
windows  reports  a  memory  access  violation  for  networks  that 
use  the  TCP  module.  This  adds  a  destructor  that  will  fix 
one  of  the  problems  causing  this  error.  This  fix  is  from 
Andras  Varga  and  is  included  in  subsequent  releases  of 
IPSuite . 


Line  195 

//Added  per  Andres  to  fix  error  when  terminating 
application 

TcpModule : : ~TcpModule  ( ) 

{ 

//  clear  unused  TCB  or  active  connections 
TcbList :: iterator  iter  =  tcb_list . begin () ; 
while  (iter  !=  tcb_list . end ( ) ) 

{ 

TcpTcb  *tcb_block  =  (TcpTcb  *)  iter->second; 
while  (tcb_block->tcp_rcv_rec_list . length ( )  > 

0)  { 

SegRecord*  seg_rec  =  (SegRecord  *) 
tcb_block->tcp_rcv_rec_list . pop ( ) ; 

delete  seg_rec->pdata; 

} 

delete  tcb_block; 
iter  ++; 

} 
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while  (! bw_msg_q . empty  0 ) 
delete ( (cMessage  * ) bw_msg_q . pop ( ) ) ; 
delete  tcpdelay; 
delete  cwnd_size; 
delete  send_seq_no; 
delete  rec_ack_no; 
delete  goodput;  //jak  for  goodput 
delete  avg_goodput ;  //jak  for  goodput 
} 


Fixes  -  When  closing  OMNeT  or  rebuilding  a  network, 
windows  reports  a  memory  access  violation  for  networks  that 
use  the  TCP  module.  This  adds  a  destructor  and  populates 
it  with  code  that  was  in  the  finish  method.  This  fix  will 
correct  one  of  the  problems  causing  this  error.  This  fix 
is  from  Andras  Varga  and  is  included  in  subsequent  releases 
of  IPSuite. 


Line  238 
Add 

//jak  -  name  vectors  for  recording  goodput 

goodput  =  new  cOutVector ( "Goodput ") ; 

avg_goodput  =  new  cOutVector ( "Avg_Goodput " ) ; 

rec_bits  =  new  cOutVector ( "Rec_Bits ") ; 

span  =  strToSimtime ( "2s" ) ;  //jak-time  span  to 
consider  in  goodput  calcs 

bits  =  0;//jak  -  initialize 
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WATCH (bits) ;// jak  for  goodput 


Fixes  -  Initialize  vectors  and  variables  for  goodput 
calculations . 


Line  259 
Delete 


//  clear  unused  TCB  or  active  connections 
TcbList :: iterator  iter  =  tcb_list . begin () ; 
while  (iter  !=  tcb_list . end ( ) ) 

{ 

TcpTcb  *tcb_block  =  (TcpTcb  *)  iter->second; 
while  (tcb_block->tcp_rcv_rec_list . length ( )  > 

0)  { 

SegRecord*  seg_rec  =  (SegRecord  *) 
tcb_block->tcp_rcv_rec_list . pop ( ) ; 

delete  seg_rec->pdata; 

} 

delete  tcb_block; 
iter  ++; 

} 


delete  tcpdelay; 
delete  cwnd_size; 
delete  send_seq_no; 
delete  rec_ack_no; 
delete  rec_seq_no; 
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Fixes  -  When  closing  OMNeT  or  rebuilding  a  network, 
windows  reports  a  memory  access  violation  for  networks  that 
use  the  TCP  module.  This  adds  a  destructor  that  will  fix 
one  of  the  problems  causing  this  error.  This  fix  is  from 
Andras  Varga  and  is  included  in  subsequent  releases  of 
IPSuite . 


Line  755-776 
Uncomment 

Fixes  -  Client  application  will  continue  to  wait  for  a 
closed  message  from  TCP  module  until  a  timeout  is  received 
and  an  abort  is  initiated.  This  code  ends  a  closed  message 
to  the  client  application  even  if  connection  not  being 
aborted.  Unknown  why  it  was  commented  out  other  than  the 
mechanism  does  not  work  if  the  complete  message  being 
received  is  large. 


Line  850 
Add 

//jak  -  calculate  goodput  whenever  a  packet  is 
received  from  the  server. 

if  (eventsource  ==  FROM_IP) 

{ 

//remove  messages  older  than  the  window  of 

interest 

while  (! bw_msg_q . empty ( )  &&  ( ( ( (cMessage 

* ) bw_msg_q .tail ( ) ) ->time stamp ( ) ) <= ( simTime ( ) -span) ) ) 

delete  ((cMessage  * ) bw_msg_q . pop ( ) ) ; 
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double  qbits  =  numBitsInQueue (bw_msg_q) ; 
//calc  total  bits  received  in  window 

if  (qbits>0) 

goodput->record ( (qbits- ( (cMessage 
* ) bw_msg_q .tail ( ) ) -> length ( ) ) / ( simTime ( ) - ( (cMessage 
* ) bw_msg_q . tail ( ) ) ->t imestamp ( ) ) ) ;  //divide  the  bits 
received  by  the  time  span  -  oldest  message  is  removed  to 
allow  the  bits  to  reflect  those  received  in  an  actual  span 
of  time  and  make  the  calculation  more  accurate. 

avg_goodput->record (bits/ simTime ( ) ) ; 

//average  over  entire  run 

if  (! bw_msg_q . empty  0 ) 

rec_bit s->record ( ( (cMessage 
*) bw_msg_q . tail  0) ->length ());/ /record  bits  received 

} 

Fixes  -  Calculates  goodput  whenever  a  new  message  is 
received  from  the  server. 


Line  2255 
Add 

//jak  -  record  bits  received 

cMessage  *bw_msg  =  (cMessage  *)  pdata->dup ( ) ; 
bits  =  bits+bw_msg->length(); 
bw_msg->setTimestamp (simTime ( ) ) ; 
bw_msg_q. insert (bw_msg) ; 

Fixes  -  Records  the  size  of  the  message  received  to 
perform  goodput  calculations. 
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Line  2261 


Add 

//jak  -  flushes  duplicated  part  of  message  in 
current  packet 

flushQueue (bw_msg_q,  (tcb_block->rcv_nxt 

tcb_block->seg_seq) ,  false) ; 

bits  =  bits  -  ( (tcb_block->rcv_nxt  -  tcb_block- 

>seg_seq) *  8 ) ; 

Fixes  -  Flushes  that  part  of  a  message  that  has 
already  been  recorded  to  prevent  double  counting  a  message. 


Line  2268 
Add 

//jak  -  record  parts  of  messages  received  out  of 
order  for  accurate  reflection  of  goodput 

cMessage  *bw_msg  =  (cMessage  *)  pdata->dup ( ) ; 

bits  =  bit s+bw_msg->length ( )  ; 

bw_msg->setTimestamp ( simTime ( ) ) ; 

bw_msg_q. insert (bw_msg) ; 

Fixes  -  Records  messages  that  were  received  out  of 
order  to  ensure  accurate  accounting  for  goodput 
calculations . 


IPSuite-2  0  04  0322 /Transport \UDP\UDPProces sing . cc 
Line  147 
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Add 


ipIfPacket->setDif f ServCodePoint (udpIfPacket- 
>getCodePoint  ( ) ) ;  //--added  by  jak  to  transfer  DSCP 
to  IP  packet 

Fixes  -  Populates  the  DSCP  in  the  IP  Header  TOS .  This 
was  not  previously  done  even  though  the  mechanism  existed. 

B .  COMPONENTS 

// - 

II  f lie :  INF . ned 

//  author:  James  Knoll 

// 

//  Date:  13  May,  2004 

// 

//  This  is  an  implementation  of  an  INE  based  upon  the 
//  Taclane  description  found  in  Analysis  of  Quintum 
//  Tenor  Vocoding  for  Support  for  Secure  Voice,  written  by 
//  Hucke,  Ed,  Nguyen,  Quang,  Teng,  Weden,  Goodrich,  Callis, 
//  Bart,  Ron,  Wadler,  Andrew,  Arendale,  Ron,  Et .  al . 

//  It  is  composed  of  this  file,  an  encoder,  and  a  decoder. 

//  Plain  text  is  sent  in  the  plainin  gate  and  is  encrypted 
//  and  sent  out  the  cypherOut  gate.  Encrypted  packets  are 
//  sent  into  the  INE  via  the  cipherin  gate  and  is  decrypted 
//  and  output  through  the  plainOut  gate.  The  INE  was 
/ /  created  to  change  the  length  of  the  IP  header  rather 


//  than  encapsulating  the  message  in  a  new  message  in  order 
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//  to  save  on  resources.  As  a  result  the  decrypted  packets 
//  still  contain  padding  in  the  IP  header,  but  are  the 
//  correct  length  in  the  UDP  header. 

// - 

import 

"LinkLayer " , 

"INEEncode", 

"INEDecode"; 

module  INE 
gates : 

in:  plainin;  //unencoded  packets  in 
in:  cypherin;  //encoded  packets  in 
out:  plainOut;  //decoded  packets  out 
out:  cypherOut ;/ /encoded  packets  out 
submodules : 

plainProcess :  INEEncode;  //Encodes  the  plaintext 

display:  "p=l 0 0 , 60 ; i=f ork" ; 

cypherProcess :  INEDecode;  //Decodes  the  cyphertext 

display:  "p=l 60 , 60 ; i=f ork" ; 

plainnetif  :  LinkLayer; .. //Handles  the  Link  layer 
information 

parameters : 

NWIName  =  "PPPModule"; 
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display :  "p=8  0 ,  12  0 , row; i=if ace" ; 

cyphernetif  :  LinkLayer;  //  Handles  the  Link 
layer  information 

parameters : 

NWIName  =  "PPPModule" ; 
display :  "p=12  0 ,  12  0 , row; i=if ace" ; 

connections  nocheck: 

//  connections  to  network  outside 
plainin  -->  plainnetif .physin; 

plainnet If . InputQueueOut  -->  plainProcess .physin; 
cyphernetif . outputQueueIn  <--  plainProcess . physOut ; 
cypherOut  <--  cyphernetif .physOut; 

cypherin  -->  cyphernetif .physin; 

cyphernetif . InputQueueOut  -->  cypherProcess .physin; 
plainnet If . outputQueueIn  <--  cypherProcess . physOut ; 
plainOut  <--  plainnetif .physOut ; 

endmodule 

// - 

//  file:  INEEncode . ned 
//  author:  James  Knoll 
// 
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//  Date:  13  May,  2004 

// 

//  An  implementation  of  an  INE  encoder  based  upon  the 
//  Taclane  description  found  in  Analysis  of  Quintum 
//  Tenor  Vocoding  for  Support  for  Secure  Voice,  written  by 
//  Hucke,  Ed,  Nguyen,  Quang,  Teng,  Weden,  Goodrich,  Callis, 
//  Bart,  Ron,  Wadler,  Andrew,  Arendale,  Ron,  Et .  al . 

// - 

simple  INEEncode 
parameters : 
gates : 

in:  physin;  //in  from  network  interface 
out:  physOut ; / /out  to  network  interface 
endsimple 

// - 

//  file:  INEEncode . cc 
//  author:  James  Knoll 
// 

//  Date:  13  May,  2004 

// 

//  An  implementation  of  an  INE  encoder  based  upon  the 
//  Taclane  description  found  in  Analysis  of  Quintum 


//  Tenor  Vocoding  for  Support  for  Secure  Voice,  written  by 
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//  Hucke,  Ed,  Nguyen,  Quang,  Teng,  Weden,  Goodrich,  Callis, 
//  Bart,  Ron,  Wadler,  Andrew,  Arendale,  Ron,  Et .  al . 

// - 

#include  <omnetpp.h> 

class  INEEncode  :  public  cSimpleModule 

{ 

public : 

Module_Class_Members ( INEEncode,  cSimpleModule,  0); 
virtual  void  handleMessage (cMessage  *msg) ; 

}; 

Def ine_Module (INEEncode)  ; 

void  INEEncode :: handleMessage (cMessage  *msg) 

{ 

double  msg_length  =  msg->length ( ) / 8 ;  //length  in  Bytes 

//Calculate  encoded  length  by  add  12  bytes  of  security 
//  information  to  the  message  and  then  pad  to  a  48  byte 
//  increment.  Another  20  bytes  of  security  information 
//  is  then  added  along  with  a  new  20  byte  IP  header. 
msg_length  =  ceil ( (msg_length+12) /48) *48+40; 
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msg->setLength (msg_length* 8 ) ;  //length  in  bits 

send(msg,  "physOut"); 

} 

// - 

//  file:  INEDecode . ned 
//  author:  James  Knoll 
// 

//  Date:  13  May,  2004 

// 

//  An  implementation  of  an  INE  decoder  based  upon  the 
//  Taclane  description  found  in  Analysis  of  Quintum 
//  Tenor  Vocoding  for  Support  for  Secure  Voice,  written  by 
//  Hucke,  Ed,  Nguyen,  Quang,  Teng,  Weden,  Goodrich,  Callis, 
//  Bart,  Ron,  Wadler,  Andrew,  Arendale,  Ron,  Et .  al . 

// - 

simple  INEDecode 
parameters : 
gates : 

in:  physin;  //in  from  network  interface 
out:  physOut ; / /out  to  network  interface 
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endsimple 


// 


//  file:  INEDecode.cc 
//  author:  James  Knoll 
// 

//  Date:  13  May,  2004 

// 

//  An  implementation  of  an  INE  encoder  based  upon  the 
//  Taclane  description  found  in  Analysis  of  Quintum 
//  Tenor  Vocoding  for  Support  for  Secure  Voice,  written  by 
//  Hucke,  Ed,  Nguyen,  Quang,  Teng,  Weden,  Goodrich,  Callis, 
//  Bart,  Ron,  Wadler,  Andrew,  Arendale,  Ron,  Et .  al . 

// - 

#include  <omnetpp.h> 

class  INEDecode  :  public  cSimpleModule 

{ 

public : 

Module_Class_Members ( INEDecode,  cSimpleModule,  0); 
virtual  void  handleMessage (cMessage  *msg) ; 

}; 

Def ine_Module (INEDecode)  ; 

void  INEDecode :: handleMessage (cMessage  *msg) 
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{ 


double  msg_length  =  msg->length ( ) / 8 ;  //Length  in  bytes 

//To  find  the  length  of  the  decoded  packet,  the 

//  20  bytes  of  IP  header  and  the  20  bytes  of  security 

//  header  are  first  removed.  The  padding  is  not 

//  removed,  but  the  additional  12  bytes  of  security 

//  header  is.  For  these  simulation  the  additional 

//  padding  in  the  IP  header  is  not  important  since  the 

//  UDP  header  will  still  be  the  original  length. 

msg_length  =  msg_length-4 0-12 ;  //does  not  remove 

padding 

msg->setLength (msg_length* 8 ) ;  //length  in  bits 

send (msg, "physOut " ) ; 

} 

// - 

//  file:  traf f icUDPHost . ned 
//  author:  James  Knoll 
// 

//  Date:  26  Apr,  2004 

// 

//  UDP  application  created  to  simulate  background  network 
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//  traffic.  The  client  Continuously  transmits  based  upon 
//  the  data  rate  specified.  The  server  application  handles 
//  incoming  messages  by  recording  the  desired  metrics  such 
//  as  delay  and  then  deleting  the  packet.  A  UDP 
//  application  was  chosen  to  simulate  network  traffic  since 
//  it  was  able  to  be  adjusted  to  easily  provide  different 
//  levels  of  network  saturation  and  because  the  metrics 
//  were  easier  to  obtain  from  a  single  application. 

// - 

import 

"LinkLayer " , 

"NetworkLayer " , 

"traf f icUDPUpperLayers " ; 

module  traf f icUDPHost 
parameters : 

dest_addr  :  string,  //list  of  destination  addresses 
local_port  :  numeric  const,  //client  port 
dest_port  :  numeric,  //server  port 

msg_length  :  numeric,  //  Max  length  of  a  message 

(bit s ) 

start_delay  :  bool,  //delay  start  of  transmit? 

traffic_rate  :  numeric,  //rate  traffic  to  be 

generated 
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local_addr  :  string 


numOfPorts  :  numeric,  //allows  connection  to 

multiple  nodes 

routingFile  :  string;  //file  name  of  routing  file 
for  this  host 

gates : 

in :  in [ ] ; 

out :  out  [  ] ; 

submodules : 

udpApp :  traf f IcUDPUpperLayers ; 
parameters : 

dest_addr  =  dest_addr, 
local_port  =  local_port, 
dest_port  =  dest_port, 
msg_length  =  msg_length, 
start_delay  =  start_delay, 
traffic_rate  =  traf f ic_rate, 
local_addr  =  local_addr, 

udpClient iName  =  "traf f IcUDPClientApp" , 

//specifies  app  to  use 

udpServerlName  =  "traf f IcUDPServerApp" ; 

//specifies  app  to  use 

display :  "p=8  9,  68 ; b=4  0 , 24 , rect " ; 

networkLayer :  NetworkLayer ; 

parameters : 
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IPForward 


0 


//this  node  will  not 


forward  traffic  intended  for  a  different  host 

numOfPorts  =  numOfPorts, 
routingFile  =  routingFile; 
gatesizes : 

physin [numOfPorts] , 
physOut [numOfPorts] ; 
display:  "p=87 , 155 ; i=f ork" ; 
netif  :  LinkLayer [numOfPorts ] ; 
parameters : 

NWIName  =  "PPPModule" ;  //specify 

layer  to  use 

display :  "p=8  0 , 22  0 , row; 1=1 f ace" ; 
connections  nocheck: 

//  transport  connections 

networkLayer . UDPOut  -->  udpApp . f rom_ip; 
networkLayer . UDPIn  <--  udpApp . to_ip; 

//  connections  to  other  nodes 

for  1=0 . . numOfPort s-1  do 

in[i]  -->  netif [1] .physin; 

out[i]  <--  netif [1] .physOut; 

netif  [1]  . InputQueueOut 
networkLayer . physin [ i ] ; 


link 


—  > 
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net If [ i ] . outputQueueIn  <-- 

networkLayer . physOut [i] ; 

endf or ; 

endmodule 

// - 

//  file:  traf f icUDPUpperLayers . ned 
//  author:  James  Knoll 
// 

//  Date:  26  Apr,  2004 

// 

//  UDP  application  created  to  simulate  background  network 
//  traffic.  The  client  continuously  transmits  based  upon 
//  the  data  rate  and  the  server  discards  the  messages. 

// - 

import  "UDPProcessing" ; 
import  "traf f icUDPApp" ; 

module  traf f IcUDPUpperLayers 
parameters : 

dest_addr  :  string,  //list  of  destination 

addresses 

local_port  :  numeric  const,  //client  port 
dest_port  :  numeric,  //server  port 
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msg_length  : 


numeric 


//  Max  length  of  a  message 


(bit s ) 

start_delay  :  bool,  //delay  start  of  transmit 

traffic_rate  :  numeric,  //rate  traffic  is  to 
generated 

local_addr  :  string, 

udpClient iName  :  string,  //client  app  to  use 
udpServerlName  :  string;  //server  app  to  use 
gates : 

in:  from_ip; 
out:  to_ip; 
submodules : 

udpProcessing :  UDPProcessing; 
gatesizes : 

f rom_applicat ion [ 2 ] , 
to_applicat ion [ 2 ]  ; 
display:  "p=94 , 1 05 ; i=f ork" ; 
udpClientl:  udpClient IName  like  traf f icUDPApp; 
parameters : 

dest_addr  =  dest_addr, 
local_port  =  local_port, 
dest_port  =  dest_port, 
msg_length  =  msg_length, 
start_delay  =  start_delay, 
traffic_rate  =  traf f ic_rate. 


be 
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local_addr  =  local_addr; 
display :  "p=134 , 4  3 ; b=4  8 , 32 , rect " ; 

udpServerl :  udpServerlName  like  traf f icUDPApp; 
parameters : 

local_port=dest_port ; 
display :  "p=51 , 42 ; b=4  0 , 24 , rect " ; 
connections  nocheck: 

from_ip  -->  udpProcessing . f rom_ip; 

to_ip  <--  udpProcessing.to_ip; 

udpProcessing . to_applicat ion [ 0 ]  --> 

udpClientl . from_udp; 

udpProcessing . f rom_applicat ion [ 0 ]  <-- 

udpClientl .to_udp; 

udpProcessing . to_applicat ion [ 1 ]  --> 

udpServerl . from_udp; 

udpProcessing . f rom_applicat ion [ 1 ]  <-- 

udpServerl . to_udp; 

display :  "p=l 0 , 1 0 ; b=157 , 14  0 , rect " ; 

endmodule 

// - 

//  file:  traf f icUDPApp . ned 
//  author:  James  Knoll 
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// 


//  Date:  26  Apr,  2004 

// 

//  UDP  application  created  to  simulate  background  network 
//  traffic.  The  client  continuously  transmits  based  upon 
//  the  data  rate  and  the  server  discards  the  messages. 

// - 

// 

//  Peer  of  traf f icUDPServerApp .  Sends  UDP  packets  to 
//  randomly  chosen  destinations  at  random  intervals. 

//  Destinations  are  chosen  from  the  dest_addresses 
//  parameter. 

// 

simple  traf f icUDPClientApp 
parameters : 

local_port  :  numeric  const, 

dest_port  :  numeric  const,  //must  match  far  end 
server  local  port 

msg_length  :  numeric  const,  //  Max  length  of  a 
message  (bits) 

start_delay  :  bool,  //delay  start  of  transmit 

traffic_rate  :  numeric,  //rate  traffic  to  be 
generated 

local_addr  :  string. 
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dest_addr:  string;  //  destination  IP  address 
gates : 

in:  from_udp; 
out:  to_udp; 
endsimple 

// 

//  Peer  of  traf f icUDPClientApp .  At  the  moment  just  discards 
//  received  packets. 

// 

simple  traf f icUDPServerApp 
parameters : 

local_port  :  numeric  const; 
gates : 

in:  from_udp; 
out:  to_udp; 
endsimple 

// - 

//  file:  traf f icUDPApp . h 
//  author:  James  Knoll 
// 

//  Date:  26  Apr,  2004 

// 

//  UDP  application  created  to  simulate  background  network 
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//  traffic.  The  client  continuously  transmits  based  upon 


//  the  data  rate  and  the  server  discards  the  messages. 
// - 

#ifndef  _ TRAFFICUDPAPP_H _ 

#define  _ TRAFFICUDPAPP_H _ 

#include  <vector> 

#include  <omnetpp.h> 

#include  "basic_const s . h" 

#include  " IPInterf acePacket . h" 

// 

//  UDP  server  app . 

// 

class  traf f IcUDPServerApp  :  public  cSimpleModule 

{ 

protected : 

int  numReceived;  //number  of  messages  received 

cOutVector  delay_v;  //records  delay 

cOutVector  receive_v; / /records  average  number 

messages  received  per  second 

public : 


of 
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Module_Class_Members (traf f icUDPServerApp, 
cSimpleModule,  0); 

virtual  void  initialize () ; 

virtual  void  handleMessage (cMessage  *msg) ; 

}; 


// 

//  UDP  client  app . 

// 


class  traf f IcUDPClientApp  :  public  cSimpleModule 

{ 


protected : 

enum  MsgKinds  //types  of  messages 

{ 

TRAFFIC, 

VOIP_DATA, 

DATA_COLLECT, 

TIMEOUT_THINK 

}; 


std::string  nodeName;  //used  to  determine  which 

application  to  use 

int  localPort,  destPort;  //numbers  not  important  as 
long  as  local  matches  remote  dest 

int  msgLength;  //length  of  each  message 
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bool  startDelay; / /delay  before  starting  to  transmit? 
double  traf f icRate; //bits  per  second  to  send 
IPAddress  localAddr; 

std : : vector<IPAddress>  destAddresses ;  //ability  to 
randomly  send  to  diff  addrs 

double  msginterval ;  //time  between  messages 

int  numSent;  //number  of  messages  sent 

cOutVector  send_v;  //average  number  of  msgs  sent  per 
second 

//  chooses  random  destination  address 
IPAddress  chooseDestAddr ( ) ; 

public : 

Module_Class_Members (traf ficUDPCl lent App, 
cSimpleModule,  0); 

virtual  void  initialize () ; 

virtual  void  handleMessage (cMessage  *msg)  ; 

}; 


#endif 

// - 
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//  file:  traf f icUDPApp . cc 
//  author:  James  Knoll 
// 

//  Date:  26  Apr,  2004 

// 

//  UDP  application  created  to  simulate  background  network 
//  traffic.  The  client  continuously  transmits  based  upon 
//  the  data  rate  and  the  server  discards  the  messages. 

// - 

#include  <omnetpp.h> 

#include  "traf f icUDPApp . h" 

# include  "UDPInterf acePacket_m . h" 

#include  "StringTokenizer . h" 

Def ine_Module (traf f IcUDPServerApp) ; 

void  traf f IcUDPServerApp : :initialize  () 

{ 

numReceived  =  0;  //number  of  messages  received 
WATCH (numReceived) ; 

delay_v . setName ( "delay_time" ) ;  //delay  between  when 


message  sent  and  received 


receive_v . setName ( "receive_rate" ) ;  //msg  received 

divided  by  elapsed  simTime 

} 


//Receive  message,  record  metrics,  and  discard 
void  traf f icUDPServerApp : : handleMessage (cMessage  *msg) 
{ 


//cast  msg  as  UDP  Interface  Packet  and  retrieve  payload 

UDPInterf acePacket  *udpIfPacket  = 

check_and_cast<UDPInterf acePacket  *> (msg) ; 

cMessage  *payload  =  udpIfPacket->decapsulate ( ) ; 

//get  specifics  about  message  and  print 
IPAddress  src  =  udpIfPacket->getSrcAddr ( ) ; 

IPAddress  dest  =  udpIfPacket->getDestAddr ( ) ; 
int  sentPort  =  udpIfPacket->getSrcPort ( )  ; 
int  recPort  =  udpIfPacket->getDestPort ( ) ; 
simtime_t  sent  =  payload->creat ionTime ( ) ; 
simtime_t  arrive  =  udpIfPacket->arrivalTime ( ) ; 

ev  <<  "Packet  received:  "  <<  payload  <<  endl; 

ev  <<  "Payload  length:  "  <<  (payload->length ( ) / 8 )  <<  " 
bytes"  <<  endl; 
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ev  <<  "Src/Port:  "  <<  src  <<  "  /  "  <<  sentPort  <<  " 

IT  • 
r 

ev  <<  "Dest/Port:  "  <<  dest  <<  "  /  "  <<  recPort  << 

endl  ; 

ev  <<  "Sent/Arrive :  "  <<  sent  <<  "  /  "  <<  arrive  << 
endl  ; 

//record  delay  and  average  number  received 
delay_v .record ( simTime ( ) -sent ) ; 
numReceived++; 

receive_v . record (numReceived/ simTime ( ) ) ; 

/ / discard  msg 
delete  udpIfPacket ; 
delete  payload; 

} 

/ / =============================================== 

Def ine_Module (traf f IcUDPClientApp) ; 

void  traf f IcUDPClientApp : linitialize  () 

{ 

send_v . setName ( " send_rate" ) ;  //set  name  of  vector 
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//get  parameters 

localPort  =  par ( " local_port " ) ; 

destPort  =  par ( "dest_port " ) ; 

msgLength  =  par ( "msg_length" ) ; 

startDelay  =  par ( " start_delay " ) ; 

trafficRate  =  par ( "traf f ic_rate" ) ; 

const  char  *localAddress  =  par ( " local_addr " ) ; 

localAddr  =IPAddress ( localAddress ) ; 

//parse  destination  addresses 

const  char  *destAddrs  =  par ( "dest_addr " ) ; 

StringTokenizer  tokenizer (destAddrs) ; 
const  char  *token; 

while  ((token  =  tokenizer . nextToken ())! =NULL) 
de St Addresses . push_back ( IPAddress (token) ) ; 

msginterval  =  (msgLength/traf f icRate) ; //how  fast  do  we 
send  messages 

/ / initialize 
numSent  =  0; 

WATCH (numSent) ; 

cMessage  *timer  =  new  cMessage ( " sendTimer " ) ;  //self 
message  for  next  transmit 
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//schedule  first  message 
if  (startDelay) 

scheduleAt (msglnterval+dblrand ( ) ,  timer) ; 

else 

scheduleAt (dblrand 0 ,  timer); 

} 

/ /handle  incoming  msgs 

void  traf f icUDPClientApp : : handleMessage (cMessage  *msg) 

{ 


scheduleAt ( simTime 0 +msglnterval ,  msg) ;  //schedule  next 
message 

char  msgName [ 32 ] ; 

sprintf (msgName, "udpAppData-%d" ,  numSent) ; 

//create  payload 

cMessage  *payload  =  new  cMessage (msgName) ; 
payload->setLength (msgLength)  ; 

//header  information  to  be  passed  on 
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UDPInterf acePacket  *udpIfPacket  =  new 

UDPInterf acePacket ()  ; 

udpIfPacket->encapsulate (payload)  ; 

IPAddress  destAddr  =  chooseDestAddr ( ) ; 

IPAddress  locAddr  =  localAddr; 

udpIfPacket->setSrcAddr (locAddr) ; 

udpIfPacket->setDestAddr (destAddr) ; 

udpIfPacket->setSrcPort (localPort) ; 

udpIfPacket->setDestPort (destPort) ; 

//print  header  info  to  user  interface 

ev  <<  "Packet  sent:  "  <<  payload  <<  endl; 

ev  <<  "Payload  length:  "  <<  (payload->length ( ) / 8 )  <<  " 

bytes"  <<  endl; 

ev  <<  "Src/Port:  "  <<  locAddr  <<  "  /  "  <<  localPort  << 
endl  ; 

ev  <<  "Dest/Port:  "  <<  destAddr  <<  "  /  "  <<  destPort  << 
endl  ; 

send (udpIfPacket ,  "to_udp");  //send  msg 

//record  average  number  of  messages  sent 
numSent++; 

send_v . record (numSent / simTime ( ) ) ; 
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} 


//randomly  choose  a  destination 

IPAddress  traf f icUDPClientApp : : chooseDestAddr ( ) 

{ 

int  k  =  intrand (destAddresses . size ( ) ) ; 
return  destAddresses [k]  ; 

} 

// - 

//  file:  voipUDPHost . ned 
//  author:  James  Knoll 
// 

//  Date:  13  Apr,  2004 

// 

//  This  is  a  UDP  application  to  send  a  burst  of 

//  conversation  to  the  specified  address,  and  then  wait  for 

//  a  reply.  A  conversation  should  be  started  by  only  one 

/ /  node  and  the  delay  before  replying  must  be  longer  than 

//  the  delay  or  the  nodes  will  step  on  each  other.  Call 

//  cycle  is  accomplished  by  setting  a  timer  within  both 

//  nodes  to  start  and  stop  conversations  at  a  predetermined 

//  interval.  If  random  intervals  are  used,  the  same  value 

//  should  be  passed  to  both  nodes  in  the  conversation  since 

//  there  is  not  any  synchronization  mechanism  in  place. 
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// 


import 

"LinkLayer " , 

"NetworkLayer " , 

" voipUDPUpperLayers " ; 

module  voipUDPHost 
parameters  : 

local_addr  :  string, 

dest_addr:  string,  //  Destination  IP  address 
local_port  :  numeric  const, 

dest_port  :  numeric  const,  //must  match  far  end 
local  port 

voice_length  :  numeric  const,  //length  of  a  voice 
conversation  segment 

initiate  :  bool,  //delay  start  of  transmit  on 
receiving  end 

codec_rate  :  numeric  const,  //analog  to  digital 
conversion  encoding 

reply_delay  : numeric  const,  //Time  to  pause  before 
a  response  begins 

frame_size  inumeric  const,  //length  of  a  frame 
talk_cycle : numeric,  //percent  of  off  hook  time 
call_length:  numeric,  //length  of  a  call 
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init_delay:  numeric;  //amount  to  delay  before  the 
first  conversation 

numOfPorts  :  numeric  const,  //allows  connection  to 
multiple  nodes 

routingFile  :  string;  /routing  file  to  use 
gates : 

in :  in [ ] ; 
out :  out  [  ] ; 
submodules : 

udpApp :  voipUDPUpperLayers ; 
parameters : 

local_addr  =  local_addr, 
dest_addr  =  dest_addr, 
local_port  =  local_port, 
dest_port  =  dest_port, 
voice_length  =  voice_length, 
initiate  =  initiate, 
codec_rate  =  codec_rate, 
reply_delay  =  reply_delay, 
talk_cycle  =  talk_cycle, 
call_length  =  call_length, 
init_delay  =  init_delay, 
frame_size  =  frame_size, 

udpClient iName  =  " voipUDPClientApp" ; 

//client  app  to  use 
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display :  "p=8  9,  68 ; b=4  0 , 24 , rect " ; 


networkLayer :  NetworkLayer ; 
parameters : 

IPForward  =  0,  //node  does  not  forward 

numOfPorts  =  numOfPorts, 

routingFile  =  routingFile;  //routing  file 

to  use 

gatesizes : 

physin [numOfPorts] , 
physOut [numOfPorts] ; 
display:  "p=87 , 155 ; i=f ork" ; 
netif  :  LinkLayer [numOfPorts ] ; 
parameters : 

NWIName  =  "PPPModule" ;  //link  layer  to  use 
display :  "p=8  0 , 22  0 , row; i=if ace" ; 
connections  nocheck: 

//  transport  connections 

networkLayer . UDPOut  -->  udpApp . f rom_ip; 
networkLayer . UDPIn  <--  udpApp . to_ip; 

//  connections  to  other  nodes 
for  1=0 . . numOfPort s-1  do 

in[i]  -->  netif [1] .physin; 
out[i]  <--  netif [1] .physOut; 
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netif [i] . inputQueueOut 


—  > 


networkLayer . physin [ i ]  ; 

netif [i] . outputQueueIn 
networkLayer . physOut [i]  ; 

endf or  ; 

endmodule 

// - 

//  file:  voipUDPUpperLayers . ned 
//  author:  James  Knoll 
// 

//  Date:  13  Apr,  2004 

// 

//  This  is  a  UDP  application  to  send  a  burst  of 
//  conversation  to  the  specified  address,  and  then  wai 
//  a  reply. 

// - 

import  "UDPProcessing" ; 
import  " voipUDPApp" ; 

module  voipUDPUpperLayers 
parameters : 

local_addr  :  string,  //local  IP  address 
dest_addr:  string,  //  Destination  IP  address 


<  — 


for 
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local_port  :  numeric  const, 

dest_port  :  numeric  const,  //must  match  far  end 
local  port 

voice_length  :  numeric  const,  //length  of  a  voice 
conversation  segment 

initiate  :  bool,  //delay  start  of  transmit  on 
receiving  end 

codec_rate  :  numeric  const,  //analog  to  digital 
conversion  encoding 

reply_delay  : numeric  const,  //Time  to  pause  before 
a  response  begins 

frame_size  inumeric  const,  //length  of  a  frame 

talk_cycle : numeric,  //percent  of  off  hook  time 

call_length:  numeric,  //length  of  a  call 

init_delay:  numeric;  //amount  to  delay  before  the 
first  conversation 

udpClient iName  :  string;  //client  to  use 
gates : 

in:  from_ip; 

out:  to_ip; 
submodules : 

udpProcessing :  UDPProcessing; 
gatesizes : 

f rom_applicat ion [ 1 ] , 
to_applicat ion [ 1 ]  ; 
display:  "p=94 ,  1 05 ; i=f ork"  ; 
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udpClientl:  udpClient iName  like  voipUDPApp; 


parameters : 

local_addr  =  local_addr, 
dest_addr  =  dest_addr, 
local_port  =  local_port, 
dest_port  =  dest_port, 
voice_length  =  voice_length, 
initiate  =  initiate, 
codec_rate  =  codec_rate, 
reply_delay  =  reply_delay, 
frame_size  =  frame_size, 
talk_cycle  =  talk_cycle, 
call_length  =  call_length, 
init_delay  =  init_delay; 
display :  "p=134 , 4  3 ; b=4  8 , 32 , rect " ; 
connections  nocheck: 

from_ip  -->  udpProcessing . f rom_ip; 
to_ip  <--  udpProcessing . to_ip; 

—  > 

<  — 

display :  "p=l 0 , 1 0 ; b=157 , 14  0 , rect " ; 


udpProcessing . to_applicat ion [ 0 ] 
udpClientl . from_udp; 

udpProcessing . f rom_applicat ion [ 0 ] 
udpClientl . to_udp; 
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endmodule 


// - 

//  file:  voipUDPApp . ned 
//  author:  James  Knoll 
// 

//  Date:  13  Apr,  2004 

// 

//  This  is  a  UDP  application  to  send  a  burst  of 
//  conversation  to  the  specified  address,  and  then  wait  for 
//  a  reply. 

// - 

simple  voipUDPClientApp 
parameters : 

local_addr  :  string,  //local  IP  address 

dest_addr:  string,  //  Destination  IP  address 

local_port  :  numeric  const,  //local  port  number 

dest_port  :  numeric  const,  //must  match  far  end 
local  port 

voice_length  :  numeric  const,  //length  of  a  voice 
conversation  segment 

initiate  :  bool,  //delay  start  of  transmit  on 
receiving  end 
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codec_rate  :  numeric  const,  //analog  to  digital 
conversion  encoding 

reply_delay  : numeric  const,  //Time  to  pause  before 
a  response  begins 

frame_size  inumeric  const,  //length  of  a  frame 

talk_cycle : numeric,  //percent  of  off  hook  time 

call_length:  numeric,  //length  of  a  call 

init_delay:  numeric;  //amount  to  delay  before  the 
first  conversation 

gates : 

in:  from_udp; 
out:  to_udp; 
endsimple 

// - 

//  file:  voipUDPApp.h 
//  author:  James  Knoll 
// 

//  Date:  13  Apr,  2004 

// 

//  This  is  a  UDP  application  to  send  a  burst  of 
//  conversation  to  the  specified  address,  and  then  wait  for 
//  a  reply. 

// - 
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#ifndef  _ VOIPUDPAPP_H 


#define  _ VOIPUDPAPP_H _ 

#include  <vector> 

#include  <omnetpp.h> 

#include  "basic_const s . h" 

#include  " IPInterf acePacket . h" 

class  voipUDPClientApp  :  public  cSimpleModule 

{ 

protected : 

enum  MsgKinds  //types  of  msgs 

{ 

TRAFFIC, 

VOIP_DATA, 

DATA_COLLECT, 

TIMEOUT_THINK, 

TIMEOUT_CALL 

}; 


int  localPort,  destPort;  //dest  port  must  match  remote 

local 

IPAddress  localAddr; 

IPAddress  destAddr; 
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double  voiceLength; 
seconds 

bool  initiate; 

double  codecRate; 

double  replyDelay; 

double  frameSize; 

double  talkCycle; 

simtime_t  callLength; 

simtime_t  InitDelay; 
conversation 


//length  of  voice  transmission  in 

//initiate  conversation? 

//encoding  rate 

//delay  before  beginning  to  speak 
//length  of  a  frame  in  seconds 
//off  hook  to  on  hook  ratio 
//length  of  a  call 

//time  to  delay  before  beginning 


int  burstCount;  //number  of  msgs  left  to  send 
int  burstNumber ;  //number  of  msgs  in  a  burst 
int  burstSize;  //size  of  each  msg  payload 

//jitter  calculation 
double  delay; 
double  old_delay; 
double  jitter; 

//current  state 
bool  talk; 
bool  listen; 
bool  call_estab; 
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//self  msgs 

cMessage  *t imeout_think; 
cMessage  *t imeout_call ; 
cMessage  *voip_data; 

/ / metrics 
int  numSent; 
int  numReceived; 
simtime_t  lastRec; 
simtime_t  lastSend; 
cOutVector  send_v; 
cOutVector  delay_v; 
cOutVector  receive_v; 
cOutVector  inst_send_v; 
cOutVector  inst_rec_v; 
cOutVector  jitter_v; 

//handles  creating  and  sending  a  msg 
virtual  void  sendMessage ( ) ; 

public : 

Module_Class_Members ( voipUDPClientApp, 

0)  ; 

virtual  void  initialize () ; 


cSimpleModule, 
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virtual  void  handleMessage (cMessage  *msg) ; 


}; 


#endif 

// - 

//  file:  voipUDPApp . cc 
//  author:  James  Knoll 
// 

//  Date:  13  Apr,  2004 

// 

//  This  is  a  UDP  application  to  send  a  burst  of 
//  conversation  to  the  specified  address,  and  then  wait  for 
//  a  reply. 

// - 

#include  <omnetpp.h> 

#include  "voipUDPApp . h" 

# include  "UDPInterf acePacket_m . h" 

#include  "StringTokenizer . h" 

Def ine_Module ( voipUDPClientApp) ; 

void  voipUDPClientApp : :initialize  () 

{ 
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//set  vector  names 


send_v . setName ( " send_rate" ) ; 
receive_v . setName ( "receive_rate" ) ; 
inst_send_v . setName ( " inst_send_rate" ) ; 
inst_rec_v . setName ( " inst_rec_rate" ) ; 
j itter_v . setName ( " j itter " )  ; 
delay_v . setName ( "delay_time" ) ; 

/ / initialize 
old_delay  =  0; 
jitter  =  0; 
delay  =  0; 

lastRec  =  simTimeO; 
lastSend  =  simTimeO; 
call_estab  =  false; 
numSent  =  0; 
numReceived  =  0; 

//read  parameters 

localPort  =  par ( " local_port " ) ; 

destPort  =  par ( "dest_port " ) ; 

voiceLength  =  par ( " voice_length" ) ;  //length  of  voice 
transmission  in  seconds 
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initiate  =  par  ( "initiate" ) ;  //does  this  host  initiate 
conversation 

codecRate  =  par ( "codec_rate" ) ;  //kbps  of  codec 

replyDelay  =  par ( "reply_delay" ) ;  //delay  before 

beginning  to  speak 

frameSize  =  par ( "frame_size" ) ;  //length  of  a  frame  in 
seconds 

talkCycle  =  par ( "talk_cycle" ) ;  //off  hook  to  on  hook 
ratio 

callLength  =  par ( "call_length" ) ;  //length  of  a  call 

initDelay  =  par ( " init_delay " ) ;  //time  to  delay  before 
beginning  conversation 

//convert  address  strings  to  IPAddress 

const  char  *localAddress  =  par ( " local_addr " ) ; 

localAddr  =IPAddress ( localAddress ) ; 

const  char  *destAddress  =  par ( "dest_addr " ) ; 

destAddr  =IPAddress (destAddress )  ; 

burstNumber  =  ceil  (voiceLength/f rameSize)  ;  //number  of 
msgs  in  a  burst 

burstSize  =  (frameSize*codecRate)  +  (12*8) ;  //size  of 
msg  with  RTP  header 
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//timeout  msg  creation 

t imeout_think  =  new 
cMessage ("TIMEOUT_THINK", TIMEOUT_THINK) ;  //if  timer 
expires  before  next  voice  packet  received,  node  will  begin 
transmitting 

timeout_call  =  new 
cMessage ("TIMEOUT_CALL", TIMEOUT_CALL) ;  //timer  to  tell  when 
to  go  on  and  off  hook 

voip_data  =  new  cMessage ( "VOIP_DATA" ,  VOIP_DATA) ; 
//schedules  next  send 


scheduleAt (simTime () +initDelay,  t imeout_call ) ; 

//schedule  first  transmission 

} 


void  voipUDPClientApp :: handleMessage (cMessage  *msg) 

{ 


//if  msg  is  from  remote  destination 
if  (  (! (msg->isSelfMessage ( ) ) )  ) 

{ 

ev<<"Received  a  message  from  remote  dest  \n"; 

if  (listen)  //in  listen,  reschedule  think  timer  to 
begin  transmitting 

{ 
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if  (t imeout_think->isScheduled ( ) ) 

{ 

cancelEvent (t imeout_think) ; 

} 

scheduleAt (simTime () +replyDelay, 
t imeout_think) ; 

} 

else  if  (!talk)  //enter  listen  and  schedule  delay 

{ 

listen=true; 

scheduleAt (simTime () +replyDelay, 
t imeout_think) ; 

ev<<  "Receiving  conversation.  Enter  listen 

mode.  \n"; 

} 

//get  payload 

UDPInterf acePacket  *udpIfPacket  = 

check_and_cast<UDPInterf acePacket  *> (msg) ; 

cMessage  *payload  =  udpIfPacket->decapsulate ( ) ; 

//parse  and  print 

IPAddress  src  =  udpIfPacket->getSrcAddr ( ) ; 

IPAddress  dest  =  udpIfPacket->getDestAddr ( ) ; 
int  sentPort  =  udpIfPacket->getSrcPort ( ) ; 
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int  recPort  =  udpIfPacket->getDestPort ( ) ; 


simtime_t  sent  =  payload->creat ionTime ( ) ; 
simtime_t  arrive  =  udpIfPacket->arrivalTime ( ) ; 

ev  <<  "Packet  received:  "  <<  payload  <<  endl; 

ev  <<  "Payload  length:  "  <<  (payload->length ( ) / 8 ) 

<<  "  bytes"  <<  endl; 

ev  <<  "Src/Port:  "  <<  src  <<  "  /  "  <<  sentPort  <<  " 

IT  • 
r 

ev  <<  "Dest/Port:  "  <<  dest  <<  "  /  "  <<  recPort  << 

endl  ; 

ev  <<  "Sent/Arrive :  "  <<  sent  <<  "  /  "  <<  arrive  << 

endl  ; 


//record  metrics 
delay=  arrive-sent ; 
delay_v . record (delay) ; 

numReceived++; 

receive_v . record (numReceived/ simTime ( ) ) ; 

inst_rec_v .record ( pay 1 o ad- > length ( ) / (simTime ( ) - 
lastRec) ) ; 

lastRec  =  simTime (); 

jitter  =  jitter+ (abs (old_delay-delay) -jitter) /16; 
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old_delay  =  delay; 


j itter_v . record ( j itter) ; 

//clean  up 
delete  udpIfPacket ; 
delete  payload; 

} 

//if  message  is  to  transmit  a  voip  msg 

else  if  ( (msg->kind ( ) ==VOIP_DATA)  && 

>isSelfMessage () ) 

{ 

if  (burstCount>0 ) 

{ 

sendMessage ( )  ; 

} 

else 

error ("No  message  to  send");  //should 

reach  here 

} 

//if  msg  is  to  start  sending 

else  if  ( (msg->kind 0  ==  TIMEOUT_THINK) ) 

{ 

burstCount  =  burstNumber; 
talk=true; 


msg- 


not 
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listen=f alse; 


if  (call_estab) 

sendMessage ( ) ; 

} 

//if  msg  is  for  call  cycle 

else  if  ( (msg->kind 0  ==  TIMEOUT_CALL) ) 

{ 

if  ( ! call_estab)  //start  call 

{ 

ev<<"Begin  call  \n"; 
call_estab  =  true; 

if  (initiate)  //does  this  node  initiate  the 
conversation? 

{ 

if  (t imeout_think->isScheduled ( ) ) / /left  over 

timeout 

cancelEvent (t imeout_think) ; 

scheduleAt (simTime () +frameSize, 
timeout_think) ;  //schedule  first  send 

talk=true; 

listen=f alse; 

} 

scheduleAt (simTime () +callLength,  t imeout_call ) ; 
//schedule  time  to  terminate  call 
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} 


else  //end  call 

{ 

call_estab  =  false; 
if  (t imeout_think->isScheduled ( ) ) 
cancelEvent (t imeout_think)  ; 
if  ( voip_data->isScheduled ( )  ) 
cancelEvent (voip_data) ; 
talk=f alse; 
listen=f alse; 

scheduleAt (simTime () +  ( (callLength/talkCycle* 

100)-  callLength) ,  timeout_call) ;  //schedule  time  of  next 
call 

} 

} 

else 

{ 

error ("Could  not  determine  origin  of  message (%d) 
(forgot  to  add  t imeout ? ) \n" , msg->kind ( ) ) ;  //should  not  get 
here 

} 

} 


//create  and  send  msg 

void  voipUDPClientApp : : sendMessage ( ) 
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{ 

char  msgName [ 32  ]  ; 

sprintf (msgName, "udpAppData-%d" ,  numSent) ; 

//create  payload 

cMessage  *payload  =  new  cMessage (msgName,  VOIP_DATA) ; 
payload->setLength (burstSize) ; 
payload->setPriority  (46) ; 

/ /header  info  for  next  layer 

UDPInterfacePacket  *udpIfPacket  =  new 

UDPInterf acePacket () ; 

udpIfPacket->encapsulate (payload) ; 

udpIfPacket->setSrcAddr (localAddr) ; 

udpIfPacket->setDestAddr (destAddr) ; 

udpIfPacket->setSrcPort (localPort)  ; 

udpIfPacket->setDestPort (destPort) ; 

udpIfPacket->setCodePoint (46)  ; 

//print  info  about  packet 

ev  <<  "Packet  sent:  "  <<  payload  <<  endl; 

ev  <<  "Payload  length:  "  <<  (payload->length ( ) / 8 )  <<  " 

bytes"  <<  endl; 

ev  <<  "Src/Port:  "  <<  localAddr  <<  "  /  "  <<  localPort 
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ev  <<  "Dest/Port:  "  <<  destAddr  <<  "  /  "  <<  destPort  << 
endl ; 

send (udpIfPacket ,  "to_udp");  //send  the  message 

//average  number  sent 
numSent++; 

send_v . record (numSent / simTime ( ) ) ; 

//packet  by  packet  send  rate  in  bits 

inst_send_v .record ( pay 1 o ad- > length ( ) / (simTime ( ) - 
lastSend) ) ; 

lastSend  =  simTime (); 

/ /  schedule  next  sending 
if  (burstCount>l ) 

{ 

scheduleAt (simTime ( ) +frameSize,  voip_data) ; 
burstCount--;  //keep  track  of  number  left  to  send 

} 

else  //done  talking,  wait  for  reply 

{ 

talk=f alse; 

} 

} 
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// 


//  file:  wredbox.ned 
//  author:  James  Knoll 
// 

//  Date:  24  May,  2004 

// 

//  Application  to  prioritize  VoIP  msgs  and  monitor 
throughput.  A  combination  of  CBWFQ  and  WRED  but  not  a 
complete  implementation.  This  is  provided  as  a  separate 
node,  but  could  be  integrated  into  a  router.  The  current 
implementation  only  recognizes  high  and  low  priority 
traffic  based  upon  whether  or  not  a  DSCP  of  46  is  present 
in  the  TOS  field.  Throughput  is  calculated  and  recorded 
for  each  queue.  The  pass  in  and  out  gates  provide  a  path 
without 

// - 


simple  wredApp 
parameters : 

bw_max :  numeric,  //maximum  bandwidth  to  allocate 

to  HPQ 

win:  numeric,  //time  span  for  bandwidth 

calculations 

hpq_min_thresh :  numeric,  //minimum  queue  size 

before  implementing  WRED 
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hpq_max_thresh :  numeric,  //maximum  queue  size 

before  implementing  WRED 

hpq_mpd:  numeric,  //maximum  percentage  of  packets 

to  drop 

lpq_min_thresh :  numeric,  //minimum  queue  size 

before  implementing  WRED 

lpq_max_thresh :  numeric,  //maximum  queue  size 

before  implementing  WRED 

lpq_mpd:  numeric,  //maximum  percentage  of  packets 

to  drop 

max_q_len:  numeric,  //max  queue  size  before  tail 

drop 

n:  numeric;  //weight  factor 

gates : 

in:  gin; 
out :  qOut ; 
endsimple 

module  wredBox 
parameters : 

bw_max :  numeric, 

to  HPQ 

win:  numeric; 

calculations 

gates : 


//maximum  bandwidth  to  allocate 


//time  span  for  bandwidth 
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in:  passin; 


out:  passOut; 
in:  qin; 
out :  qOut ; 
submodules : 

wredap:  wredApp; 
parameters : 

bw_max  =  bw_max, 
win  =  win; 

display:  "p=l 60 , 60 ; i=f ork" ; 

net If 1  :  LinkLayer ; 
parameters : 

NWIName  =  "PPPModule" ; 
display:  "p=8 0 , 12 0 ; i=if ace" ; 
net If 2  :  LinkLayer; 
parameters : 

NWIName  =  "PPPModule"; 
display :  "p=l 60 ,  12  0 ; i=if ace" ; 

connections : 

passin  -->  netlf2 .physin; 

passOut  <--  netlf2 .physOut ; 
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netlf2 . inputQueueOut 


—  > 


net If 2 . outputQueueIn; 


//pass  through 

qin  -->  netif 1 .physin; 
qOut  <--  netIfl.physOut; 
net If 1 . inputQueueOut  -->  wredap.qln; 
net If I . outputQueueIn  <--  wredap . qOut ; 
endmodule 


// - 

//  file:  wredbox.h 
//  author:  James  Knoll 
// 

//  Date:  24  May,  2004 

// 

//  Application  to  prioritize  VoIP  msgs  and  monitor 
throughput.  A  combination  of  CBWFQ  and  WRED  but  not  a 
complete  implementation.  Provided  as  a  separate  node,  but 
could  be  integrated  into  a  router. 

// - 


#ifndef  _ WREDBOX_H_ 

# define  _ WREDBOX_H_ 

#include  <vector> 
#include  <omnetpp.h> 
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class  wredApp  :  public  cSimpleModule 

{ 

protected : 

double  bwMax;  //maximum  bandwidth  to  allocate  to 

HPQ 

double  win;  //time  span  for  bandwidth  calculations 

cQueue  hpq;  / /high  priority  queue 

cQueue  Ipq;  //low  priority  queue 

cMessage  *next_send;  //self  timing  message 

double  hpg_bits;  //length  of  all  msgs  in  hpq 
double  lpq_bits;  //length  of  all  msgs  in  ipq 
cQueue  hpg_bw_q;  //stores  msgs  for  bw  calcs 
cQueue  lpq_bw_g;  //stores  msgs  for  bw  calcs 
simtime_t  old_time;  //oldest  time  to  include  in  bw 

calc 

int  hpq_min_thresh;  //minimum  queue  size  before 

implementing  WRED 

int  hpq_max_thresh;  //maximum  queue  size  before 

implementing  WRED 

int  hpg_mpd;  //maximum  percentage  of 


packets  to  drop 
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int  lpq_min_thresh; 
implementing  WRED 

int  lpq_max_thresh; 
implementing  WRED 

int  lpq_mpd; 
packets  to  drop 

int  max_q_len; 

drop 

double  hpq_avg_q_len; 
double  lpq_avg_g_len; 
double  n; 

cOutVector  hpgsize_v; 
cOutVector  lpgsize_v; 
cOutVector  hpbw_v; 
cOutVector  lpbw_v; 


//minimum  queue  size  before 

//maximum  queue  size  before 

//maximum  percentage  of 

//max  queue  size  before  tail 

//average  length  of  queue 
//average  length  of  queue 
//weight  factor 

// 


void  sendMessage ( ) ; 
void  serviceQueues ( )  ; 

double  bw ( ) ;  //calculate  bandwidth  used 

bool  drop (int  min_thresh,  int  max_thresh,  int  mpd, 
double  avg_q_len) ;  //determine  if  drop 


public : 

Module_Class_Members (wredApp,  cSimpleModule,  0); 
virtual  void  initialize ()  ; 
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virtual  void  handleMessage (cMessage  *msg) ; 

}; 

#endif 

// - 

//  file:  wredbox.cc 
//  author:  James  Knoll 
// 

//  Date:  24  May,  2004 

// 

//  Application  to  prioritize  VoIP  msgs  and  monitor 
throughput.  A  combination  of  CBWFQ  and  WRED  but  not  a 
complete  implementation.  Provided  as  a  separate  node,  but 
could  be  integrated  into  a  router. 

// - 

#include  <omnetpp.h> 

#include  <math.h> 

#include  "wredbox.h" 

#include  " IPDatagram . h" 

Def ine_Module (wredApp) ; 

void  wredApp :: initialize  ( ) 
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{ 


/ / parameters 

bwMax  =  par ( "bw_max" ) ; 

win  =  par ("win"); 

hpq_min_thresh  =  par ( "hpq_min_thresh" ) ; 
hpq_max_thresh  =  par ( "hpq_max_thresh" ) ; 
hpq_mpd  =  par ( "hpq_mpd" ) ; 
lpq_min_thresh  =  par ( " lpq_min_thresh" ) ; 
lpq_max_thresh  =  par ( " lpq_max_thresh" ) ; 
lpq_mpd  =  par ( " lpq_mpd" ) ; 
max_q_len  =  par ( "max_q_len" ) ; 
n  =  par ( "n" ) ; 

//set  vector  names 
hpqsize_v . setName ( "HPQ_size"  )  ; 
lpqsize_v . setName ( "LPQ_size" )  ; 
hpbw_v . setName ( "HP_BW" ) ; 
lpbw_v . setName ("LP_BW") ; 

/ / initialize 
hpq_bits  =  0; 
lpq_bits  =  0; 

hpq_avg_q_len  =  0; 
lpq_avg_q_len  =  0; 
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//timing  message  for  servicing  the  queues 
next_send  =  new  cMessage ( "NEXT_SEND" ) ; 


void  wredApp :: handleMessage (cMessage  *msg) 

{ 

//if  timer,  service  queues 
if  (msg->isSelfMessage ( ) ) 
serviceQueues ()  ; 

/ /if  new  msg 
else 
{ 

IPDatagram  *ipDatagram  =  check_and_cast<IPDatagram 

*> (msg) ; 


//if  high  pri  msg,  insert  in  hpq 

if  ( ipDatagram->dif f ServCodePoint ( )  ==  46) 

{ 

hpq_avg_q_len  =  (hpq_avg_q_len  *  ( 1-pow ( . 5 , n) ) ) 

+  (hpq . length ( )  *  pow(.5,n));  //wred  algorithm  for 

weighting  the  queue  length  to  damp  out  transient  effects 


//do  I  drop  this  msg? 
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if  ( (hpq . length ( )  >=  max_q_len)  |  | 

drop (hpq_min_thresh,  hpq_max_thresh,  hpq_mpd, 

hpq_avg_q_len) ) 

{ 

delete  (ipDatagram) ;  //dropped 
ev<<"Drop  from  HPQ\n"; 

} 

else 

{ 

hpq . insert ( ipDatagram) ;  //store  in  the 

queue 

} 

} 

//if  low  pri  msg,  insert  in  Ipq 
else 
{ 

lpq_avg_q_len  =  ( lpq_avg_q_len  *  ( 1-pow ( . 5 , n) ) )  + 

( ipq . length ( )  *  pow(.5,n));  //wred  algorithm  for  weighting 

the  queue  length  to  damp  out  transient  effects 


//do  I  drop  this  msg? 

if  (( ipq . length ( )  >=  max_q_len)  |  | 

drop ( lpq_min_thresh,  lpq_max_thresh,  lpq_mpd, 

lpq_avg_q_len) ) 

{ 
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delete  (ipDatagram) ;  //dropped 
ev<<"Drop  from  LPQ\n"; 

} 

else 

{ 

Ipq . insert ( ipDatagram) ;  //insert  into  queue 

} 

} 

//schedule  next  service  of  queues 

if  ( ! next_send->isScheduled ( ) ) 

if  (parent Module ( ) ->gate ( "qOut " ) ->isBusy ( )  ) 

scheduleAt (parentModule ( ) ->gate ( "qOut " ) - 
>transmissionFinishes () ,  next_send) ; 

else 

scheduleAt (simTime () ,  next_send) ; 

} 

} 

void  wredApp : : serviceQueues  ( ) 

{ 

double  bw_var  =  bw  ( ) ;  //determine  bw  used  by  hpq 

//service  hpq  if  not  over  bw  allocation 
if  (bw_var<bwMax  &&  ! hpq . empty () ) 
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{ 


//insert  in  bw  calc  queue 

cMessage  *bw_msg  =  (cMessage  *)  ( (cMessage 
* ) hpq .tail ( ) ) ->dup ( ) ; 

bw_msg->setTimestamp ( simTime ( ) ) ;  //set  timestamp 
needed  for  bw  calcs 

hpq_bits  =  hpq_bit s+bw_msg->length ( )  ;  //add  to 
length  of  msgs  in  bw  queue 

hpq_bw_g . insert (bw_msg) ;  //store  for  future  calcs 

send  (  (cMessage  *)  hpq.popO,  "gOut");  //send  msg 

hpqsize_v . record (hpq . length ());/ /record  queue  size 


//schedule  next  send 

if  ( ! next_send->isScheduled ( )  &&  (! hpq . empty ( ) 

! Ipg . empty ( ) ) ) 

if  (parent Module ( ) ->gate ( "gOut " ) ->isBusy ( ) ) 

scheduleAt (parentModule ( ) ->gate ( "gOut "  )  - 
>t ransmissionFinishes () ,  next_send) ; 

else 

scheduleAt (simTime () ,  next_send) ; 

} 

/ / service  ipg 

else  if  (! ipg . empty  0 ) 

{ 
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//insert  in  bw  calc  queue 

cMessage  *bw_msg  =  (cMessage  *)  ( (cMessage 
* ) Ipq .tail  0 ) ->dup ( ) ; 

bw_msg->setTimestamp ( simTime ( ) ) ;  //set  timestamp 
needed  for  bw  calcs 

lpq_bits  =  lpq_bit s+bw_msg->length ( ) ;  //add  to 
length  of  msgs  in  bw  queue 

lpq_bw_q . insert (bw_msg) ;  //store  for  future  calcs 

send  (  (cMessage  *)  Ipq.popO,  "gOut");  //send  msg 

lpqsize_v . record ( ipq . length ());/ /record  queue  size 


//schedule  next  send 

if  ( ! next_send->isScheduled ( )  &&  (! hpg . empty ( )  |  | 

! ipq . empty ( ) ) ) 

if  (parent Module ( ) ->gate ( "gOut " ) ->isBusy ( ) ) 

scheduleAt (parentModule ( ) ->gate ( "qOut " ) - 
>transmissionFinishes () ,  next_send) ; 

else 

scheduleAt (simTime () ,  next_send) ; 

} 

else  if  (! hpg . empty  0 )  //service  anyway  so  that  bw  not 
wasted 

{ 

//insert  in  bw  calc  queue 
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cMessage  *bw_msg  =  (cMessage  *) ( (cMessage 
* ) hpq .tail ( ) ) ->dup  ( ) ; 

bw_msg->setTimestamp ( simTime ( ) ) ; / /set  timestamp 

needed  for  bw  calcs 

hpq_bits  =  hpq_bit s+bw_msg->length ( ) ;  //add  to 
length  of  msgs  in  bw  queue 

hpq_bw_q . insert (bw_msg) ;  //store  for  future  calcs 

send  (  (cMessage  *)  hpq.popO,  "qOut");  //send  msg 

hpqsize_v . record (hpq . length  0) ;  //record  queue  size 


//schedule  next  send 

if  ( ! next_send->isScheduled ( )  &&  (! hpq . empty ( ) 

! Ipq . empty ( ) ) ) 

if  (parent Module ( ) ->gate ( "qOut " ) ->isBusy ( )  ) 

scheduleAt (parentModule ( ) ->gate ( "qOut " ) - 
>transmissionFinishes () ,  next_send) ; 

else 

scheduleAt (simTime () ,  next_send) ; 

} 

} 


double  wredApp : : bw ( ) 

{ 

double  bw_var; 
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old_time  =  simTime () -win; / /oldest  time  to  include 

bool  done  =  false; 

//remove  messages  older  than  the  window 
while  (! lpq_bw_q . empty ( )  &&  !done) 

{ 

if  ( ( (cMessage  * ) lpq_bw_q . tail ( ) ) ->t imestamp ( ) >= 

old_time) 

done  =  true;  //done  purging  messages 

else 

{ 

lpq_bits  =  lpq_bits  -  ( (cMessage 

* ) lpq_bw_q . tail ( ) ) ->length ( ) ;  //reduce  bits  counted 

delete  lpq_bw_q . pop ( ) ;  //delete  message 

} 

} 

//calc  and  record  bw 
if  (lpq_bits  >  0) 

bw_var  =  lpq_bits/ (simTime ()-(( (cMessage 

* ) lpq_bw_q .tail ( ) ) ->t imestamp ( ) ) ) ; 

else 

bw_var  =  0; 

lpbw_v . record (bw_var)  ; 
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done 


false; 


//remove  messages  older  than  the  window 
while  (! hpq_bw_q . empty ( )  &&  !done) 

{ 

if  ( ( (cMessage  * ) hpq_bw_q . tail ( ) ) ->t imestamp ( ) >= 

old_time) 

done  =  true;  //done  purging  messages 

else 

{ 

hpq_bits  =  hpq_bits  -  ( (cMessage 

* ) hpq_bw_q . tail ( ) ) ->length ( ) ;  //reduce  bits  in  queue 

delete  hpq_bw_q . pop ( ) ;  //delete  msg 

} 

} 

//calc  and  record  bw 
if  (hpq_bits  >  0) 

bw_var  =  hpq_bits/ (simTime ()-(( (cMessage 

* ) hpq_bw_q .tail ( ) ) ->t imestamp ( ) ) ) ; 

else 

bw_var  =  0; 

hpbw_v . record (bw_var)  ; 

return  bw_var;//hpq  bw  usage 
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} 


//determine  random  drop  based  on  WRED 

bool  wredApp : : drop ( int  min_thresh,  int  max_thresh,  int  mpd, 
double  avg_q_len) 

{ 

bool  drop_val; 


if  (avg_q_len  >  min_thresh)  / /only  drop  if  over 
min_thresh  for  queue  length 

{ 


double  drop_prob; 


drop_prob  =  (  (avg_q_len  -  min_thresh) 
-  min_thresh) )  /  mpd;  //probability  that 
message  will  be  dropped 


/  (max_thresh 
an  individual 


if  (drop_prob  >=  dblrandO)  //randomly  determine  if 

we  drop 

drop_val  =  true; 
else 

drop_val  =  false; 

} 

else 

drop_val  =  false; 
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return  (drop_val) ; 


} 

#  filename:  nodel_l.irt 

#  routing  table  for  node  1 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0  to  client  2 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.0.1 
MTU:  1500  Metric:  1 

if conf igend . 

route : 

default:  10.0.1.0  255.255.255.0  G  0 

pppO 


routeend . 

# - 

#  filename:  nodel_2.irt 
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#  routing  table  for  node  2 


#  author:  James  Knoll 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.0.2 
MTU:  1500  Metric:  1 

if conf igend . 

route : 

default:  10.0.1.0  255.255.255.0  G  0 

pppO 


routeend . 

# - 

#  filename:  nodel_3.irt 

#  routing  table  for  node  3 

#  author:  James  Knoll 

#  - 


if conf ig : 
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#  ethernet  card  0 


name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.0.3 
MTU:  1500  Metric:  1 

if conf igend . 

route : 

default:  10.0.1.0  255.255.255.0  G  0 

pppO 


routeend . 

# 

#  filename:  nodel_4.irt 

#  routing  table  for  node  4 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.0.4 
MTU:  1500  Metric:  1 
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if conf igend . 


route : 

default:  10.0.1.0  255.255.255.0  G  0 

pppO 


routeend . 

# 

#  filename:  nodel_5.irt 

#  routing  table  for  node  5 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.0.5 
MTU:  1500  Metric:  1 


if conf igend . 


route : 
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default:  10.0.1.0  255.255.255.0  G  0 

pppO 


routeend . 

# 

#  filename:  nodel_6.irt 

#  routing  table  for  node  6 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0  to  client  2 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.0.6 
MTU:  1500  Metric:  1 

if conf igend . 

route : 

default:  10.0.1.0  255.255.255.0  G  0 

pppO 


routeend . 
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# 


#  filename:  nodel_7.irt 

#  routing  table  for  node  7 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0  to  client  2 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.0.7 
MTU:  1500  Metric:  1 


if conf igend . 


route : 

default:  10.0.1.0  255.255.255.0  G  0 

pppO 


routeend . 

# 

#  filename:  nodel_8.irt 

#  routing  table  for  node  8 

139 


#  author:  James  Knoll 

if conf ig : 

#  ethernet  card  0  to  client  2 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.0.8 
MTU:  1500  Metric:  1 

if conf igend . 

route : 

default:  10.0.1.0  255.255.255.0  G  0 

pppO 

routeend . 

# 

#  filename:  nodel_9.irt 

#  routing  table  for  node  9 

#  author:  James  Knoll 

if conf ig : 

140 


#  ethernet  card  0  to  client  2 


name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.0.9 
MTU:  1500  Metric:  1 


if conf igend . 


route : 

default:  10.0.1.0  255.255.255.0  G  0 

pppO 


routeend . 

# 

#  filename:  nodel_10.irt 

#  routing  table  for  node  10 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.0.10 
MTU:  1500  Metric:  1 
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if conf igend . 


route : 

default:  10.0.1.0  255.255.255.0  G  0 

pppO 


routeend . 

# 

#  filename:  nodel_ll.irt 

#  routing  table  for  node  11 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.0.11 
MTU:  1500  Metric:  1 


if conf igend . 
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route : 


default:  10.0.1.0  255.255.255.0 

pppO 


routeend . 

# 

#  filename:  nodel_12.irt 

#  routing  table  for  node  12 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10 
MTU:  1500  Metric:  1 


if conf igend . 


route : 

default:  10.0.1.0  255.255.255.0 

pppO 


G  0 


0.0.12 


G  0 
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routeend . 


#  filename:  nodel_13.irt 

#  routing  table  for  node  13 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10 
MTU:  1500  Metric:  1 


if conf igend . 


route : 

default:  10.0.1.0  255.255.255.0 

pppO 


routeend . 

# - 

#  filename:  nodel_14.irt 


0.0.13 


G  0 
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#  routing  table  for  node  14 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10 
MTU:  1500  Metric:  1 


if conf igend . 


route : 

default:  10.0.1.0  255.255.255.0 

pppO 


routeend . 

# - 

#  filename:  nodel_15.irt 

#  routing  table  for  node  15 

#  author:  James  Knoll 

#  - 


0.0.14 


G  0 
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if conf ig : 


#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10 
MTU:  1500  Metric:  1 


if conf igend . 


route : 

default:  10.0.1.0  255.255.255.0 

pppO 


routeend . 

# 

#  filename:  nodel_16.irt 

#  routing  table  for  node  16 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10 
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0.0.15 


G  0 


0.0.16 


MTU:  1500  Metric:  1 


if conf igend . 


route : 

default:  10.0.1.0  255.255.255.0 

pppO 


routeend . 

# 

#  filename:  nodel_17.irt 

#  routing  table  for  node  17 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10 
MTU:  1500  Metric:  1 


if conf igend . 
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G  0 


0.0.17 


route : 


default:  10.0.1.0  255.255.255.0  G  0 

pppO 

routeend . 

# 

#  filename:  nodel_18.irt 

#  routing  table  for  node  18 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.0.18 
MTU:  1500  Metric:  1 

if conf igend . 

route : 

default:  10.0.1.0  255.255.255.0  G  0 

pppO 
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routeend . 


#  filename:  nodel_19.irt 

#  routing  table  for  node  19 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.0.19 
MTU:  1500  Metric:  1 


if conf igend . 


route : 

default:  10.0.1.0  255.255.255.0  G  0 

pppO 


routeend . 


# 
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#  filename:  nodel_20.irt 

#  routing  table  for  node  20 

#  author:  James  Knoll 


if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.0.20 
MTU:  1500  Metric:  1 


if conf igend . 


route : 

default:  10.0.1.0  255.255.255.0  G  0 

pppO 


routeend . 

# - 

#  filename:  nodel_21.irt 

#  routing  table  for  node  21 

#  author:  James  Knoll 
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# 


if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.0.21 
MTU:  1500  Metric:  1 


if conf igend . 


route : 

default:  10.0.1.0  255.255.255.0  G  0 

pppO 


routeend . 

# 

#  filename:  nodel_22.irt 

#  routing  table  for  node  22 

#  author:  James  Knoll 

#  - 

if conf ig : 
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#  ethernet  card  0 


name:  pppO  encap:  Point-to-Point  inet_addr:  10 
MTU:  1500  Metric:  1 


if conf igend . 


route : 

default:  10.0.1.0  255.255.255.0 

pppO 


routeend . 

# 

#  filename:  nodel_23.irt 

#  routing  table  for  node  23 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10 
MTU:  1500  Metric:  1 


0.0.22 


G  0 


0.0.23 


152 


if conf igend . 


route : 

default:  10.0.1.0  255.255.255.0 

pppO 


routeend . 

# 

#  filename:  nodel_24.irt 

#  routing  table  for  node  24 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10 
MTU:  1500  Metric:  1 


if conf igend . 


G  0 


0.0.24 
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route : 


default:  10.0.1.0  255.255.255.0 

pppO 


routeend . 

# 

#  filename:  nodel_25.irt 

#  routing  table  for  node  25 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10 
MTU:  1500  Metric:  1 


if conf igend . 


route : 

default:  10.0.1.0  255.255.255.0 

pppO 


G  0 


0.0.25 


G  0 
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routeend . 


#  filename:  node2_l.irt 

#  routing  table  for  node  1 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.3.1 
MTU:  1500  Metric:  1 


if conf igend . 

route : 

default:  10.0.2.0  255.0.0.0  G  0  pppO 

routeend . 

#  filename:  node2_2.irt 


#  routing  table  for  node  2 
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#  author:  James  Knoll 


if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.3.2 
MTU:  1500  Metric:  1 


if conf igend . 

route : 

default:  10.0.2.0  255.0.0.0  G  0  pppO 

routeend . 

# 

#  filename:  node2_3.irt 

#  routing  table  for  node  3 

#  author:  James  Knoll 

# 

if conf ig : 
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#  ethernet  card  0 


name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.3.3 
MTU:  1500  Metric:  1 


if conf igend . 

route : 

default:  10.0.2.0  255.0.0.0  G  0  pppO 

routeend . 

# 

#  filename:  node2_4.irt 

#  routing  table  for  node  4 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.3.4 
MTU:  1500  Metric:  1 
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if conf igend . 


route : 

default:  10.0.2.0  255.0.0.0  G  0  pppO 

routeend . 

# 

#  filename:  node2_5.irt 

#  routing  table  for  node  5 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.3.5 
MTU:  1500  Metric:  1 


if conf igend . 

route : 

default:  10.0.2.0  255.0.0.0  G  0  pppO 
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routeend . 


#  filename:  node2_6.irt 

#  routing  table  for  node  6 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.3.6 
MTU:  1500  Metric:  1 


if conf igend . 

route : 

default:  10.0.2.0  255.0.0.0  G  0  pppO 

routeend . 

#  filename:  node2_7.irt 


#  routing  table  for  node  7 


159 


#  author:  James  Knoll 


if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.3.7 
MTU:  1500  Metric:  1 


if conf igend . 

route : 

default:  10.0.2.0  255.0.0.0  G  0  pppO 

routeend . 

# 

#  filename:  node2_8.irt 

#  routing  table  for  node  8 

#  author:  James  Knoll 

# 

if conf ig : 
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#  ethernet  card  0 


name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.3.8 
MTU:  1500  Metric:  1 


if conf igend . 

route : 

default:  10.0.2.0  255.0.0.0  G  0  pppO 

routeend . 

# 

#  filename:  node2_9.irt 

#  routing  table  for  node  9 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.3.9 
MTU:  1500  Metric:  1 


161 


if conf igend . 


route : 

default:  10.0.2.0  255.0.0.0  G  0  pppO 

routeend . 

# 

#  filename:  node2_10.irt 

#  routing  table  for  node  10 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.3.10 
MTU:  1500  Metric:  1 


if conf igend . 

route : 

default:  10.0.2.0  255.0.0.0  G  0  pppO 
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routeend . 


#  filename:  node2_ll.irt 

#  routing  table  for  node  11 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.3.11 
MTU:  1500  Metric:  1 


if conf igend . 

route : 

default:  10.0.2.0  255.0.0.0  G  0  pppO 

routeend . 

#  filename:  node2_12.irt 


#  routing  table  for  node  12 
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#  author:  James  Knoll 


if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.3.12 
MTU:  1500  Metric:  1 


if conf igend . 

route : 

default:  10.0.2.0  255.0.0.0  G  0 

routeend . 

# 

#  filename:  node2_13.irt 

#  routing  table  for  node  13 

#  author:  James  Knoll 

# 

if conf ig : 


pppO 
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#  ethernet  card  0 


name:  pppO  encap:  Point-to-Point  inet_addr:  10 
MTU:  1500  Metric:  1 


if conf igend . 

route : 

default:  10.0.2.0  255.0.0.0  G 

routeend . 

# 

#  filename:  node2_14.irt 

#  routing  table  for  node  14 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10 
MTU:  1500  Metric:  1 


0.3.13 


0  pppO 


0.3.14 
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if conf igend . 


route : 

default:  10.0.2.0  255.0.0.0  G  0  pppO 

routeend . 

# 

#  filename:  node2_15.irt 

#  routing  table  for  node  15 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.3.15 
MTU:  1500  Metric:  1 


if conf igend . 

route : 

default:  10.0.2.0  255.0.0.0  G  0  pppO 
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routeend . 


#  filename:  node2_16.irt 

#  routing  table  for  node  16 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.3.16 
MTU:  1500  Metric:  1 


if conf igend . 

route : 

default:  10.0.2.0  255.0.0.0  G  0  pppO 

routeend . 

#  filename:  node2_17.irt 


#  routing  table  for  node  17 
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#  author:  James  Knoll 


if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.3.17 
MTU:  1500  Metric:  1 


if conf igend . 

route : 

default:  10.0.2.0  255.0.0.0  G  0 

routeend . 

# 

#  filename:  node2_18.irt 

#  routing  table  for  node  18 

#  author:  James  Knoll 

# 

if conf ig : 


pppO 
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#  ethernet  card  0 


name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.3.18 
MTU:  1500  Metric:  1 


if conf igend . 

route : 

default:  10.0.2.0  255.0.0.0  G  0  pppO 

routeend . 

# 

#  filename:  node2_19.irt 

#  routing  table  for  node  19 

#  author:  James  Knoll 


if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.3.19 
MTU:  1500  Metric:  1 
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if conf igend . 


route : 

default:  10.0.2.0  255.0.0.0  G  0  pppO 

routeend . 

# 

#  filename:  node2_20.irt 

#  routing  table  for  node  20 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.3.20 
MTU:  1500  Metric:  1 


if conf igend . 

route : 

default:  10.0.2.0  255.0.0.0  G  0  pppO 
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routeend . 


#  filename:  node2_21.irt 

#  routing  table  for  node  21 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.3.21 
MTU:  1500  Metric:  1 


if conf igend . 

route : 

default:  10.0.2.0  255.0.0.0  G  0  pppO 

routeend . 

#  filename:  node2_22.irt 
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#  routing  table  for  node  22 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.3.22 
MTU:  1500  Metric:  1 


if conf igend . 

route : 

default:  10.0.2.0  255.0.0.0  G  0 

routeend . 

# 

#  filename:  node2_23.irt 

#  routing  table  for  node  23 

#  author:  James  Knoll 


pppO 
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if conf ig : 


#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.3.23 
MTU:  1500  Metric:  1 


if conf igend . 

route : 

default:  10.0.2.0  255.0.0.0  G  0  pppO 

routeend . 

# 

#  filename:  node2_24.irt 

#  routing  table  for  node  24 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.3.24 
MTU:  1500  Metric:  1 
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if conf igend . 

route : 

default:  10.0.2.0  255.0.0.0  G 

routeend . 

# 

#  filename:  node2_25.irt 

#  routing  table  for  node  25 

#  author:  James  Knoll 

# 

if conf ig : 

#  ethernet  card  0 

name:  pppO  encap:  Point-to-Point  inet_addr:  10 
MTU:  1500  Metric:  1 


if conf igend . 


route : 


174 


0  pppO 


0.3.25 


default:  10.0.2.0  255.0.0.0  G  0  pppO 

routeend . 

# 

#  filename:  routerl.irt 

#  routing  table  1  for  voip  networks 

#  author:  James  Knoll 

# 

if conf ig : 

#  PPP  link  0  to  routerl 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.1.1 
MTU:  1500  Metric:  1 

#  PPP  link  1  to  node  1 

name:  pppl  encap:  Point-to-Point  inet_addr:  10.0.1.2 
MTU:  1500  Metric:  1 

#  PPP  link  2  to  node  2 

name:  ppp2  encap:  Point-to-Point  inet_addr:  10.0.1.3 
MTU:  1500  Metric:  1 

#  PPP  link  3  to  node  3 
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name:  ppp3  encap:  Point-to-Point  inet_addr:  10.0.1.4 


MTU: 

#  PPP 
name : 

MTU: 

#  PPP 
name : 

MTU: 

#  PPP 
name : 

MTU: 

#  PPP 
name : 

MTU: 

#  PPP 
name : 

MTU: 

#  PPP 
name : 


1500  Metric:  1 

link  4  to  node  4 

ppp4  encap:  Point-to-Point  inet_addr:  10.0.1.5 
1500  Metric:  1 

link  5  to  node  5 

ppp5  encap:  Point-to-Point  inet_addr:  10.0.1.6 

1500  Metric:  1 

link  6  to  node  6 

ppp6  encap:  Point-to-Point  inet_addr:  10.0.1.7 

1500  Metric:  1 

link  7  to  node  7 

ppp7  encap:  Point-to-Point  inet_addr:  10.0.1.8 

1500  Metric:  1 

link  8  to  node  8 

ppp8  encap:  Point-to-Point  inet_addr:  10.0.1.9 

1500  Metric:  1 

link  9  to  node  9 

ppp9  encap:  Point-to-Point  inet_addr:  10.0.1.10 
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MTU:  1500  Metric:  1 


#  PPP  link  10  to  node  10 

name:  ppplO  encap:  Point-to-Point  inet_addr:  10.0.1.11 
MTU:  1500  Metric:  1 

#  PPP  link  11  to  node  11 

name:  pppll  encap:  Point-to-Point  inet_addr:  10.0.1.12 
MTU:  1500  Metric:  1 

#  PPP  link  12  to  node  12 

name:  pppl2  encap:  Point-to-Point  inet_addr:  10.0.1.13 
MTU:  1500  Metric:  1 

#  PPP  link  13  to  node  13 

name:  pppl3  encap:  Point-to-Point  inet_addr:  10.0.1.14 
MTU:  1500  Metric:  1 

#  PPP  link  14  to  node  14 

name:  pppl4  encap:  Point-to-Point  inet_addr:  10.0.1.15 
MTU:  1500  Metric:  1 

#  PPP  link  15  to  node  15 

name:  pppl5  encap:  Point-to-Point  inet_addr:  10.0.1.16 
MTU:  1500  Metric:  1 
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#  PPP  link  16  to  node  16 


name : 

MTU: 

#  PPP 
name : 

MTU: 

#  PPP 
name : 

MTU: 

#  PPP 
name : 

MTU: 

#  PPP 
name : 

MTU: 

#  PPP 
name : 

MTU: 


pppl6  encap:  Point-to-Point  inet_addr:  10 
1500  Metric:  1 

link  17  to  node  17 

pppl7  encap:  Point-to-Point  inet_addr:  10 

1500  Metric:  1 

link  18  to  node  18 

pppl8  encap:  Point-to-Point  inet_addr:  10 

1500  Metric:  1 

link  19  to  node  19 

pppl9  encap:  Point-to-Point  inet_addr:  10 

1500  Metric:  1 

link  20  to  node  20 

ppp20  encap:  Point-to-Point  inet_addr:  10 

1500  Metric:  1 

link  21  to  node  21 

ppp21  encap:  Point-to-Point  inet_addr:  10 

1500  Metric:  1 


0.1.17 


0.1.18 


0.1.19 


0.1.20 


0.1.21 


0.1.22 
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#  PPP  link  22  to  node  22 


name:  ppp22  encap:  Point-to-Point  inet_addr:  10.0.1.23 
MTU:  1500  Metric:  1 

#  PPP  link  23  to  node  23 

name:  ppp23  encap:  Point-to-Point  inet_addr:  10.0.1.24 
MTU:  1500  Metric:  1 

#  PPP  link  24  to  node  24 

name:  ppp24  encap:  Point-to-Point  inet_addr:  10.0.1.25 
MTU:  1500  Metric:  1 

#  PPP  link  25  to  node  25 

name:  ppp25  encap:  Point-to-Point  inet_addr:  10.0.1.26 
MTU:  1500  Metric:  1 

#  PPP  link  26  to  node  26 

name:  ppp26  encap:  Point-to-Point  inet_addr:  10.0.1.27 
MTU:  1500  Metric:  1 

#  PPP  link  27  to  node  27 

name:  ppp27  encap:  Point-to-Point  inet_addr:  10.0.1.28 
MTU:  1500  Metric:  1 

#  PPP  link  28  to  node  28 
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name:  ppp28  encap:  Point-to-Point  inet_addr:  10.0.1.29 


MTU:  1500  Metric:  1 

#  PPP  link  29  to  node  29 

name:  ppp29  encap:  Point-to-Point  inet_addr:  10.0.1.30 
MTU:  1500  Metric:  1 

if conf igend . 


route : 

10.0.0.1 

-k 

255.255.255.255 

H 

0 

pppl 

10.0.0.2 

k 

255.255.255.255 

H 

0 

ppp2 

10.0.0.3 

k 

255.255.255.255 

H 

0 

PPP  3 

10.0.0.4 

k 

255.255.255.255 

H 

0 

PPP  4 

10.0.0.5 

k 

255.255.255.255 

H 

0 

PPP  5 

10.0.0.6 

k 

255.255.255.255 

H 

0 

PPP  6 

10.0.0.7 

k 

255.255.255.255 

H 

0 

PPP  7 

10.0.0.8 

k 

255.255.255.255 

H 

0 

PPP  8 

10.0.0.9 

k 

255.255.255.255 

H 

0 

PPP  9 

10.0.0.10 

k 

255.255.255.255 

H 

0 

pppl  0 

10.0.0.11 

k 

255.255.255.255 

H 

0 

pppl  1 

10.0.0.12 

k 

255.255.255.255 

H 

0 

PPP  12 

10.0.0.13 

k 

255.255.255.255 

H 

0 

PPP  13 

10.0.0.14 

k 

255.255.255.255 
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H 

0 

PPP  14 

10.0.0.15 

-k 

255.255.255.255 

H 

0 

pppl5 

10.0.0.16 

-k 

255.255.255.255 

H 

0 

pppl  6 

10.0.0.17 

k: 

255.255.255.255 

H 

0 

pppl7 

10.0.0.18 

k: 

255.255.255.255 

H 

0 

pppl  8 

10.0.0.19 

k: 

255.255.255.255 

H 

0 

pppl  9 

10.0.0.20 

k: 

255.255.255.255 

H 

0 

ppp2  0 

10.0.0.21 

k: 

255.255.255.255 

H 

0 

ppp2 1 

10.0.0.22 

k: 

255.255.255.255 

H 

0 

ppp22 

10.0.0.23 

k: 

255.255.255.255 

H 

0 

ppp2  3 

10.0.0.24 

k: 

255.255.255.255 

H 

0 

ppp2  4 

10.0.0.25 

k: 

255.255.255.255 

H 

0 

ppp2  5 

10.0.0.26 

k: 

255.255.255.255 

H 

0 

ppp2  6 

10.0.0.27 

k: 

255.255.255.255 

H 

0 

ppp2  7 

10.0.0.28 

k: 

255.255.255.255 

H 

0 

ppp2  8 

10.0.0.29 

k: 

255.255.255.255 

H 

0 

ppp2  9 

default : 

10.0.2.0 

255.0.0.0 

G 

0 

routeend . 


#  filename:  router2.irt 

#  routing  table  2  for  voip  networks 

#  author:  James  Knoll 
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if conf ig : 


#  PPP  link  0  to  routerl 

name:  pppO  encap:  Point-to-Point  inet_addr:  10.0.2.1 
MTU:  1500  Metric:  1 

#  PPP  link  1  to  node  1 

name:  pppl  encap:  Point-to-Point  inet_addr:  10.0.2.2 
MTU:  1500  Metric:  1 

#  PPP  link  2  to  node  2 

name:  ppp2  encap:  Point-to-Point  inet_addr:  10.0.2.3 
MTU:  1500  Metric:  1 

#  PPP  link  3  to  node  3 

name:  ppp3  encap:  Point-to-Point  inet_addr:  10.0.2.4 
MTU:  1500  Metric:  1 

#  PPP  link  4  to  node  4 

name:  ppp4  encap:  Point-to-Point  inet_addr:  10.0.2.5 
MTU:  1500  Metric:  1 

#  PPP  link  5  to  node  5 

name:  ppp5  encap:  Point-to-Point  inet_addr:  10.0.2.6 
MTU:  1500  Metric:  1 
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#  PPP  link  6  to  node  6 


name : 

MTU: 

#  PPP 
name : 

MTU: 

#  PPP 
name : 

MTU: 

#  PPP 
name : 

MTU: 

#  PPP 
name : 

MTU: 

#  PPP 
name : 

MTU: 


ppp6  encap:  Point-to-Point  inet_addr:  10.0.2.7 

1500  Metric:  1 

link  7  to  node  7 

ppp7  encap:  Point-to-Point  inet_addr:  10.0.2.8 

1500  Metric:  1 

link  8  to  node  8 

ppp8  encap:  Point-to-Point  inet_addr:  10.0.2.9 

1500  Metric:  1 

link  9  to  node  9 

ppp9  encap:  Point-to-Point  inet_addr:  10.0.2.10 

1500  Metric:  1 

link  10  to  node  10 

ppplO  encap:  Point-to-Point  inet_addr:  10.0.2.11 
1500  Metric:  1 

link  11  to  node  11 

pppll  encap:  Point-to-Point  inet_addr:  10.0.2.12 
1500  Metric:  1 
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#  PPP  link  12  to  node  12 


name:  pppl2  encap:  Point-to-Point  inet_addr:  10.0.2.13 
MTU:  1500  Metric:  1 

#  PPP  link  13  to  node  13 

name:  pppl3  encap:  Point-to-Point  inet_addr:  10.0.2.14 
MTU:  1500  Metric:  1 

#  PPP  link  14  to  node  14 

name:  pppl4  encap:  Point-to-Point  inet_addr:  10.0.2.15 
MTU:  1500  Metric:  1 

#  PPP  link  15  to  node  15 

name:  pppl5  encap:  Point-to-Point  inet_addr:  10.0.2.16 
MTU:  1500  Metric:  1 

#  PPP  link  16  to  node  16 

name:  pppl6  encap:  Point-to-Point  inet_addr:  10.0.2.17 
MTU:  1500  Metric:  1 

#  PPP  link  17  to  node  17 

name:  pppl7  encap:  Point-to-Point  inet_addr:  10.0.2.18 
MTU:  1500  Metric:  1 

#  PPP  link  18  to  node  18 
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name:  pppl8  encap:  Point-to-Point  inet_addr:  10.0.2.19 


MTU:  1500  Metric:  1 

#  PPP  link  19  to  node  19 

name:  pppl9  encap:  Point-to-Point  inet_addr:  10 
MTU:  1500  Metric:  1 

#  PPP  link  20  to  node  20 

name:  ppp20  encap:  Point-to-Point  inet_addr:  10 
MTU:  1500  Metric:  1 

#  PPP  link  21  to  node  21 

name:  ppp21  encap:  Point-to-Point  inet_addr:  10 
MTU:  1500  Metric:  1 

#  PPP  link  22  to  node  22 

name:  ppp22  encap:  Point-to-Point  inet_addr:  10 
MTU:  1500  Metric:  1 

#  PPP  link  23  to  node  23 

name:  ppp23  encap:  Point-to-Point  inet_addr:  10 
MTU:  1500  Metric:  1 

#  PPP  link  24  to  node  24 

name:  ppp24  encap:  Point-to-Point  inet_addr:  10 
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0.2.20 


0.2.21 


0.2.22 


0.2.23 


0.2.24 


0.2.25 


MTU:  1500  Metric:  1 


#  PPP  link  25  to  node  25 

name:  ppp25  encap:  Point-to-Point  inet_addr:  10.0.2.26 
MTU:  1500  Metric:  1 

#  PPP  link  26  to  node  26 

name:  ppp26  encap:  Point-to-Point  inet_addr:  10.0.2.27 
MTU:  1500  Metric:  1 

#  PPP  link  27  to  node  27 

name:  ppp27  encap:  Point-to-Point  inet_addr:  10.0.2.28 
MTU:  1500  Metric:  1 

#  PPP  link  28  to  node  28 

name:  ppp28  encap:  Point-to-Point  inet_addr:  10.0.2.29 
MTU:  1500  Metric:  1 

#  PPP  link  29  to  node  29 

name:  ppp29  encap:  Point-to-Point  inet_addr:  10.0.2.30 
MTU:  1500  Metric:  1 


if conf igend . 
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route : 
10.0.3 
10.0.3 
10.0.3 
10.0.3 
10.0.3 
10.0.3 
10.0.3 
10.0.3 
10.0.3 
10.0.3 
10.0.3 
10.0.3 
10.0.3 
10.0.3 
10.0.3 
10.0.3 
10.0.3 
10.0.3 
10.0.3 
10.0.3 
10.0.3 
10.0.3 
10.0.3 
10.0.3 


.  1 

-k 

255.255.255.255 

H 

0 

pppl 

.2 

-k 

255.255.255.255 

H 

0 

ppp2 

.3 

k: 

255.255.255.255 

H 

0 

ppp3 

.  4 

k: 

255.255.255.255 

H 

0 

ppp4 

.  5 

k: 

255.255.255.255 

H 

0 

ppp5 

.  6 

k: 

255.255.255.255 

H 

0 

ppp6 

.  7 

k: 

255.255.255.255 

H 

0 

ppp7 

.  8 

k: 

255.255.255.255 

H 

0 

ppp8 

.  9 

k: 

255.255.255.255 

H 

0 

ppp9 

.10 

k: 

255.255.255.255 

H 

0 

pppl  0 

.11 

k: 

255.255.255.255 

H 

0 

pppl  1 

.  12 

k: 

255.255.255.255 

H 

0 

pppl  2 

.  13 

k: 

255.255.255.255 

H 

0 

pppl  3 

.  14 

k: 

255.255.255.255 

H 

0 

pppl  4 

.  15 

k: 

255.255.255.255 

H 

0 

pppl  5 

.16 

k: 

255.255.255.255 

H 

0 

pppl  6 

.  17 

k: 

255.255.255.255 

H 

0 

pppl  7 

.18 

k: 

255.255.255.255 

H 

0 

pppl  8 

.19 

k: 

255.255.255.255 

H 

0 

pppl  9 

.20 

k: 

255.255.255.255 

H 

0 

ppp2  0 

.21 

k: 

255.255.255.255 

H 

0 

ppp2 1 

.22 

k: 

255.255.255.255 

H 

0 

ppp22 

.23 

k: 

255.255.255.255 

H 

0 

ppp2  3 

.24 

k: 

255.255.255.255 

H 

0 

ppp2  4 
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10.0.3.25 

-k 

255.255.255.255 

H 

0 

ppp2  5 

10.0.3.26 

-k 

255.255.255.255 

H 

0 

ppp2  6 

10.0.3.27 

k: 

255.255.255.255 

H 

0 

ppp2  7 

10.0.3.28 

k: 

255.255.255.255 

H 

0 

ppp2  8 

10.0.3.29 

k: 

255.255.255.255 

H 

0 

ppp2  9 

default : 

10.0.1.0 

255.0.0.0 

G 

0 

routeend . 

C .  NETWORKS 

// - 

//  file:  codec. ned 
//  author:  James  Knoll 
// 

//  Date:  31  May,  2004 

// 

//  Simple  voip  configuration  to  test  how  codecs  respond  to 
//  varying  the  frame  size.  The  network  consists  of  two 
/ /  voip  nodes  connected  with  a  router  and  wred  box  on  each 
//  network.  Each  set  of  runs  is  conducted  by  varying  the 
//  frame  size  with  a  fixed  CODEC  data  rate. 

// - 

import 


"voipUDPHost" 


"wredBox" 


"INE"; 


module  codec 

parameters : 

satrate  :  numeric; 
submodules : 

voipclientll :  voipUDPHost ; 
parameters : 

local_addr  =  "10.0.0.1", 
dest_addr  =  "10.0.3.1", 
local_port  =  100, 
dest_port  =  200, 

/ /  Voice  parameters 

voice_length  =  input (30s,  "Length  of  voice 
transmission:  "), 

initiate  =  input  (false,  "Initiate 

conversation?  "), 

codec_rate  =  input  (64000,  "CODEC  stream 

rate :  " ) , 


reply_delay  =  input  (4s,  "Time  to  delay 
before  replying  to  a  voice  burst:  "), 

frame_size  =  input (20ms,  "Length  of  a 

frame :  " ) , 

/ /  network  parameters 

numOfPorts  =  1,  //nodes  connected  to 
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routingFile  =  "nodel_l . irt " ; 
gatesizes : 
in[l] , 
out  [  1 ] ; 

display:  "p=45 , 1 0 0 ; i=pc" ; 
routerl :  Router; 
parameters : 

/ /  network  parameters 
numOfPorts  =  2,  //nodes  connected  to 
routingFile  =  "routerl . irt " ; 
gatesizes : 
in  [2] , 
out  [  2 ] ; 

display:  "p=l 60 , 1 0 0 ; i=ipc" ; 
wredl :  wredBox; 
parameters : 

win  =  Is,  //time  span  for  bw  calcs 

bw_max  =  input  (42000,  "Max  amount  of  bw  to 
allocate  to  high  pri  traffic:  " ) ; 

display :  "p=2 10, 100; i=bwxcon_s " ; 

voipclient2 1 :  voipUDPHost; 

parameters : 

/ /  UDP  parameters 

local_addr  =  "10.0.3.1", 

dest_addr  =  "10.0.0.1", 
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local_port  =  200, 
dest_port  =  100, 

/ /  Voice  parameters 

voice_length  =  input (30s,  "Length  of  voice 
transmission:  "), 

initiate  =  input  (true,  "Initiate 

conversation?  "), 

codec_rate  =  input  (64000,  "CODEC  stream 

rate :  " ) , 

reply_delay  =  input  (4s,  "Time  to  delay 
before  replying  to  a  voice  burst:  "), 

frame_size  =  input (20ms,  "Length  of  a 

frame :  " ) , 

/ /  network  parameters 
numOfPorts  =  1,  //nodes  connected  to 
routingFile  =  "node2_l . irt " ; 
gatesizes : 
in[l] , 
out  [  1 ] ; 

display:  "p=455 , 1 0 0 ; i=comp" ; 
router2 :  Router; 
parameters : 

/ /  network  parameters 
numOfPorts  =  2,  //nodes  connected  to 
routingFile  =  "router2 . irt " ; 
gatesizes : 

191 


in  [2] 


out  [  2 ] ; 

display:  "p=34 0 , 1 0 0 ; i=ipc" ; 
wred2 :  wredBox; 
parameters : 

win  =  Is, 

bw_max  =  input  (42000,  "Max  amount  of  bw  to 
allocate  to  high  pri  traffic:  " ) ; 

display :  "p=2  90 ,  10  0; i=bwxcon_s " ; 

connections  nocheck: 

voipclientll . out [ 0 ]  -->  routerl.in[l]; 

voipclient2 1 . out [ 0 ]  -->  router2.in[l]; 

routerl . out  [  0 ]  -->  wredl.qln; 

wredl.qOut  -->  datarate  satrate  -->  wred2 .passin; 
wred2 . passOut  -->  router2.in[0]; 

router2 . out [ 0 ]  -->  wred2.qln; 

wred2.qOut  -->  datarate  satrate  -->  wredl .passin; 
wredl . passOut  -->  routerl.in[0]; 

router2 . out [ 1 ]  -->  voipclient2 1 . in [ 0 ] ; 
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routerl . out [ 1 ]  -->  voipclientll . in [ 0 ] ; 


display:  "p=10, 18;b=345, 156"; 
endmodule 

network  directnw  :  codec 
endnetwork 

#  filename:  omnetpp.ini 

#  ini  file  for  codec. ned 

#  author:  James  Knoll 


[General ] 

preload-ned-f lies  =  *.ned  . . /mynodes/* . ned 

@c : /home/ IPSuite/nedf lies . 1st  ;  ned  files  to  load 

dynamically 

network  =  directnw 

total-stack-kb=7535 

sim-t ime-limit  =  10m  ;maximum  simulation  time  to  run 

simulation 

cpu-t ime-limit=  Ih  ;maximum  clock  time  to  run  simulation 
random-seed  =  1  ; seed  for  random  numbers 

snapshot-file  =  codec. sna  ;file  to  output  snapshots  to 
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; output-vector-file  =  codec. vec  ;file  to  output  vectors 


[Cmdenv] 

runs-to-execute=l-l 8  ; runs  to  execute  using  cmd  environment 

express-mode  =  yes  ; run  in  express  mode 

status-f requency=l 0 0 0 0 0  ; frequency  for  status  messages 

[ Tkenv] 

def ault-run=l  ; run  to  execute  for  TK  environment 

[OutVectors ] 

interval  =  10s.., ’delay  before  starting  to  record  data 
#voip  and  traffic  vectors 
*. delay_time . enabled  =  no 
*. receive_rate . enabled  =  no 
*. inst_rec_rate . enabled  =  no 
*. send_rate . enabled  =  no 
*. inst_send_rate . enabled  =  no 
*. j itter . enabled  =  no  ; jitter  in  voip  apps 
#tcp  client  vectors 
*.Send  No. enabled  =  no 
*.TCP  delay . enabled  =  no 
*.Rec  No. enabled  =  no 
*.Rec  Seq  No. enabled  =  no 
* . Cwnd  size. enabled  =  no 
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*. Goodput . enabled  =  no 


*. Avg_Goodput . enabled  =  no 
*. Rec_Bits . enabled  =  no 
#wred  vectors 
*. LP_BW . enabled  =  no 
*. HP_BW . enabled  =  yes 
*. HPQ_size . enabled  =  no 
*. LPQ_size . enabled  =  no 

[Parameters ] 

#connect ions 

* . sat_datarate  =  64000  ;data  rate  of  satellite  connection 

*.sat_error  =  0  ; satellite  BER 

*.sat_delay  =  500ms  ; delay  in  satellite  link 

#traf f ic 

*.msg_length  =  11200  ; length  of  a  message  in  bits 

* . traf f ic_rate  =  64000  ; rate  of  transmission 

#  voip  app  configuration 

* . voip_client s  =  3  ; number  of  voip  clients 

* . voice_length  =  30s  ; length  of  a  voice  burst 

* .voipclientll . initiate  =  true  ;does  this  client  initiate 
the  conversation 

*. voipclient2 1 . initiate  =  false 
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* . codec_rate 
*  .  reply_delay 
; * . f rame_size 
* . init_delay 
* . talk_cycle 
* . call_length 


5300  ;data  rate  for  voip  client 
4s  ; delay  before  sending  a  reply 
140ms  ;size  of  a  frame 
2s  ; delay  before  first  burst 
50  ;percent  off  hook 
30m  ; length  of  a  call 


#wredbox 

*.bw_max  =  48000  ;48  for  64k  and  75  for  128k 

* • hpq_min_thresh  =  40  ;when  to  start  random  drop 
* • hpq_max_thresh  =  64  ;max  drop 
*.hpq_mpd  =  10  ; percent  to  drop 

* . lpq_min_thresh  =  20  ;when  to  start  random  drop 
* . lpq_max_thresh  =  34  ;max  drop 
* . lpq_mpd  =  10  ; percent  to  drop 

*.max_q_len  =  64  ;max  queue  depth 
*.n  =  .01  ; weighting  factor 


#  TCP 

; * . clients_net 1  =  2  ; number  of  tcp  clients  in  network  1 
*. client s_net2  =  0  ; number  of  tcp  clients  in  network  2 
*.mss=1400  ;maximum  segment  size 

* . tcp . debug=true  ; debug  on 

* . message_length  =  64000000  ; length  of  message  to  transmit 
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#  processing  delays  for  all  nodes 
* . preRout ing . procdelay  =  0 

* . rout ing . procdelay  =  0.2  us 
*. localDeliver . procdelay  =  1  us 
*. send . procdelay  =  0.5  us 
*. fragmentation . procdelay  =  0.1  us 
*. icmp . procdelay  =  0 
*. tunneling . procdelay  =  0 
*. mult icast . procdelay  =  0 
*. output [*]. procdelay  =  0.2  us 
*. inputQueue . procdelay  =  0.1  us 
*. networkinterf ace . procdelay  =  0 

#  hook  names 

* . qosBehaviorClass  =  "EnqueueWithoutQoS"  ;  only 
currently  implemented 

#conf igurat ion  changes  between  runs 
[Run  1] 

output-vector-file  =  coded,  vec 
*.frame_size  =  10ms 

[Run  2] 

output-vector-file  =  codec2.vec 
*.frame_size  =  20ms 


hook 
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[Run  3] 


output-vector-file  =  codecS.vec 
* . f rame_size  =  30ms 

[Run  4] 

output-vector-file  =  codec4.vec 
*.frame_size  =  40ms 

[Run  5] 

output-vector-file  =  codecS.vec 
*.frame_size  =  50ms 

[Run  6] 

output-vector-file  =  codecG.vec 
*.frame_size  =  60ms 

[Run  7] 

output-vector-file  =  codecV.vec 
*.frame_size  =  80ms 

[Run  8] 

output-vector-file  =  codec8.vec 
*.frame_size  =  100ms 
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[Run  9] 


output-vector-file  =  codec9.vec 
*.frame_size  =  120ms 

[Run  10] 

output-vector-file  =  codeclO.vec 
*.frame_size  =  150ms 

[Run  11] 

output-vector-file  =  codecll.vec 
*.frame_size  =  200ms 

[Run  12] 

output-vector-file  =  codecl2.vec 
*.frame_size  =  250ms 

[Run  13] 

output-vector-file  =  codeclS.vec 
*.frame_size  =  300ms 

[Run  14] 

output-vector-file  =  codecll.vec 
*.frame_size  =  330ms 


[Run  15] 
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output-vector-file  =  codeclS.vec 
*.frame_size  =  350ms 

[Run  16] 

output-vector-file  =  codeclG.vec 
*.frame_size  =  400ms 

[Run  17] 

output-vector-file  =  codeclV.vec 
*.frame_size  =  450ms 

[Run  18] 

output-vector-file  =  codeclS.vec 
*.frame_size  =  500ms 

// - 

//  file:  codec_w_ine . ned 
//  author:  James  Knoll 
// 

//  Date:  31  May,  2004 

// 

//  Simple  voip  configuration  with  INEs  to  test  how  CODECs 

//  respond  to  varying  the  frame  size.  It  is  used  with 

//  codec. ned  to  show  the  effect  of  the  INE  on  the  effective 

//  data  rate.  The  network  consists  of  two  voip  nodes 
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//  connected  with  a  router  and  wred  box  on  each  network. 

//  Each  set  of  runs  is  conducted  by  varying  the  frame  size 
//  with  a  fixed  CODEC  data  rate. 

// - 

import 

"voipUDPHost", 

"wredBox" , 

"INE"; 

module  codec_w_ine 
parameters : 

satrate  :  numeric; 
submodules : 

voipclientll :  voipUDPHost; 
parameters : 

local_addr  =  "10.0.0.1", 
dest_addr  =  "10.0.3.1", 
local_port  =  100, 
dest_port  =  200, 

/ /  Voice  parameters 

voice_length  =  input (30s,  "Length  of  voice 
transmission:  "), 

initiate  =  input  (false,  "Initiate 

conversation?  "), 
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codec_rate 


input  (64000 


"CODEC  stream 


rate  :  "  ) , 

reply_delay  =  input  (4s,  "Time  to 
before  replying  to  a  voice  burst:  "), 

frame_size  =  input (20ms,  "Length 

frame :  " ) , 

/ /  network  parameters 
numOfPorts  =  1,  //nodes  connected  to 
routingFile  =  "nodel_l . irt " ; 
gatesizes : 
in[l] , 
out  [  1 ] ; 

display:  "p=45 , 1 0 0 ; i=pc" ; 
inell:  INF; 

display:  "p=l 0 0 , 1 0 0 ; i=ipc" ; 
routerl :  Router; 
parameters : 

/ /  network  parameters 
numOfPorts  =  2,  //nodes  connected  to 
routingFile  =  "routerl . irt " ; 
gatesizes : 
in  [2] , 
out  [  2 ] ; 

display:  "p=l 60 , 1 0 0 ; i=ipc" ; 
wredl :  wredBox; 


delay 


of  a 
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parameters : 


win  =  Is,  //window  size  for  bw  calcs 

bw_max  =  input  (42000,  "Max  amount  of  bw  to 
allocate  to  high  pri  traffic:  " ) ; 

display :  "p=2 10, 100; i=bwxcon_s " ; 

voipclient2 1 :  voipUDPHost ; 

parameters : 

/ /  UDP  parameters 

local_addr  =  "10.0.3.1", 

dest_addr  =  "10.0.0.1", 

local_port  =  200, 

dest_port  =  100, 

/ /  Voice  parameters 

voice_length  =  input  (30s,  "Length  of  voice 
transmission:  "), 

initiate  =  input (true,  "Initiate 

conversation?  "), 

codec_rate  =  input (64000,  "CODEC  stream 

rate :  " ) , 


reply_delay  =  input  (4s,  "Time  to  delay 
before  replying  to  a  voice  burst:  "), 

frame_size  =  input (20ms,  "Length  of  a 

frame :  " ) , 

/ /  network  parameters 

numOfPorts  =  1,  //nodes  connected  to 

routingFile  =  "node2_l . irt " ; 
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gatesizes : 


in[l] , 
out  [  1 ] ; 

display:  "p=455 , 1 0 0 ; i=comp" ; 
ine21:  INE; 

display:  "p=4 0 0 , 1 0 0 ; i=ipc" ; 
router2 :  Router; 
parameters : 

/ /  network  parameters 
numOfPorts  =  2,  //nodes  connected  to 
routingFile  =  "router2 . irt " ; 
gatesizes : 
in  [2] , 
out  [  2 ] ; 

display:  "p=34 0 , 1 0 0 ; i=ipc" ; 
wred2 :  wredBox; 
parameters : 

win  =  Is,  //window  to  use  for  bw  calcs 

bw_max  =  input  (42000,  "Max  amount  of  bw  to 
allocate  to  high  pri  traffic:  " ) ; 

display :  "p=2  90 ,  10  0; i=bwxcon_s " ; 

connections  nocheck: 

voipclientll . out [ 0 ]  -->  inell .plainin; 
inel 1 . cypherOut  -->  routerl . in [ 1 ]  ; 
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voipclient2 1 . out [ 0 ]  -->  ine2 1 . plainin; 
ine2 1 . cypherOut  -->  router2 . in [ 1 ] ; 

routerl . out  [  0 ]  -->  wredl.qln; 

wredl.qOut  -->  datarate  satrate  -->  wred2 .passin; 
wred2 . passOut  -->  router2.in[0]; 

router2 . out [ 0 ]  -->  wred2.qln; 

wred2.qOut  -->  datarate  satrate  -->  wredl .passin; 
wredl . passOut  -->  routerl.in[0]; 

router2 . out [ 1 ]  -->  ine21 . cypherin; 
ine2 1 . plainOut  -->  voipclient2 1 . in [ 0 ]  ; 

routerl . out [ 1 ]  -->  inel 1 . cypherin; 
inel 1 . plainOut  -->  voipclientll . in [ 0 ] ; 

display:  "p=10, 18;b=345, 156"; 
endmodule 

network  directnw  :  codec_w_ine 
endnetwork 
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#  filename:  omnetpp.ini 


#  ini  file  for  codec_w_ine . ned 

#  author:  James  Knoll 


[General ] 

preload-ned-f lies  =  *.ned  . . /mynodes/* . ned 

@c : /home/ IPSuite/nedf lies . 1st  ;  ned  files  to  load 

dynamically 

network  =  directnw 

total-stack-kb=7535 

sim-t ime-limit  =  10m  ;maximum  simulation  time  to  run 

simulation 

cpu-t ime-limit=  Ih  ;maximum  clock  time  to  run  simulation 
random-seed  =  1  ; seed  for  random  numbers 

snapshot-file  =  codec. sna  ;file  to  output  snapshots  to 
; output-vector-file  =  codec. vec  ;file  to  output  vectors 

[Cmdenv] 

runs-to-execute=l-50  ; runs  to  execute  using  cmd  environment 

express-mode  =  yes  ; run  in  express  mode 

status-f requency=l 0 0 0 0 0  ; frequency  for  status  messages 

[ Tkenv] 

def ault-run=l  ; run  to  execute  for  TK  environment 
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[OutVectors ] 


interval  =  10s  ;  delay  before  starting  to  record  data 

#voip  and  traffic  vectors 
*. delay_time . enabled  =  no 
*. receive_rate . enabled  =  no 
*. inst_rec_rate . enabled  =  no 
*. send_rate . enabled  =  no 
*. inst_send_rate . enabled  =  no 
*. j itter . enabled  =  no  ; jitter  in  voip  apps 
#tcp  client  vectors 
*.Send  No. enabled  =  no 
*.TCP  delay . enabled  =  no 
*.Rec  No. enabled  =  no 
*.Rec  Seq  No. enabled  =  no 
* . Cwnd  size. enabled  =  no 
*. Goodput . enabled  =  no 
*. Avg_Goodput . enabled  =  no 
*. Rec_Bits . enabled  =  no 
#wred  vectors 
*. LP_BW . enabled  =  no 
*. HP_BW . enabled  =  yes 
*. HPQ_size . enabled  =  no 
*. LPQ_size . enabled  =  no 
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[Parameters ] 


#connect ions 

* . sat_datarate  =  64000  ;data  rate  of  satellite  connection 

*.sat_error  =  0  ; satellite  BER 

*.sat_delay  =  500ms  ; delay  in  satellite  link 

#traf f ic 

*.msg_length  =  11200  ; length  of  a  message  in  bits 

* . traf f ic_rate  =  64000  ; rate  of  transmission 

#  voip  app  configuration 

* . voip_client s  =  3  ; number  of  voip  clients 

* . voice_length  =  30s  ; length  of  a  voice  burst 

* .voipclientll . initiate  =  true  ;does  this  client  initiate 
the  conversation 

*. voipclient2 1 . initiate  =  false 

*.codec_rate  =  5300  ;data  rate  for  voip  client 

* . reply_delay  =  4s  ; delay  before  sending  a  reply 

; * . f rame_size  =  140ms  ;size  of  a  frame 

*.init_delay  =  2s  ; delay  before  first  burst 

*.talk_cycle  =  50  ;percent  off  hook 

* . call_length  =  30m  ; length  of  a  call 

#wredbox 

*.bw_max  =  48000  ;48  for  64k  and  75  for  128k 
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* . hpq_min_thresh  =  40  ;when  to  start  random  drop 
* . hpq_max_thresh  =  64  ;max  drop 
*.hpq_mpd  =  10  ; percent  to  drop 

* . lpq_min_thresh  =  20  ;when  to  start  random  drop 
* . lpq_max_thresh  =  34  ;max  drop 
* . lpq_mpd  =  10  ; percent  to  drop 

*.max_q_len  =  64  ;max  queue  depth 
*.n  =  .01  ; weighting  factor 


#  TCP 

; * . clients_net 1  =  2  ; number  of  tcp  clients  in  network  1 
*. client s_net2  =  0  ; number  of  tcp  clients  in  network  2 
*.mss=1400  ;maximum  segment  size 

* . tcp . debug=true  ; debug  on 

* . message_length  =  64000000  ; length  of  message  to  transmit 

#  processing  delays  for  all  nodes 
* . preRout ing . procdelay  =  0 

* . rout ing . procdelay  =  0.2  us 
*. localDeliver . procdelay  =  1  us 
*. send . procdelay  =  0.5  us 
*. fragmentation . procdelay  =  0.1  us 
*. icmp . procdelay  =  0 
*. tunneling . procdelay  =  0 


*. mult least . procdelay  =  0 
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*. output [*]. procdelay  =  0.2  us 


* . inputQueue . procdelay  =  0.1  us 
*. networkinterf ace . procdelay  =  0 

#  hook  names 

* . qosBehaviorClass  =  "EnqueueWithoutQoS"  ;  only 
currently  implemented  within  IPSuite 

#conf igurat ion  changes  between  runs 
[Run  1] 

output-vector-file  =  coded,  vec 
*.frame_size  =  10ms 

[Run  2] 

output-vector-file  =  codec2.vec 
*.frame_size  =  20ms 

[Run  3] 

output-vector-file  =  codecS.vec 
*.frame_size  =  30ms 

[Run  4] 

output-vector-file  =  codec4.vec 
*.frame_size  =  40ms 


hook 
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[Run  5] 


output-vector-file  =  codecS.vec 
*.frame_size  =  50ms 

[Run  6] 

output-vector-file  =  codecG.vec 
*.frame_size  =  60ms 

[Run  7] 

output-vector-file  =  codecV.vec 
*.frame_size  =  70ms 

[Run  8] 

output-vector-file  =  codecS.vec 
*.frame_size  =  80ms 

[Run  9] 

output-vector-file  =  codec9.vec 
*.frame_size  =  90ms 

[Run  10] 

output-vector-file  =  codeclO.vec 
*.frame_size  =  100ms 


[Run  11] 
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output-vector-file  =  codecll.vec 
*.frame_size  =  110ms 

[Run  12] 

output-vector-file  =  codecl2.vec 
*.frame_size  =  120ms 

[Run  13] 

output-vector-file  =  codeclS.vec 
*.frame_size  =  130ms 

[Run  14] 

output-vector-file  =  codecll.vec 
*.frame_size  =  140ms 

[Run  15] 

output-vector-file  =  codeclS.vec 
*.frame_size  =  150ms 

[Run  16] 

output-vector-file  =  codeclG.vec 
*.frame_size  =  160ms 

[Run  17] 

output-vector-file  =  codecll.vec 
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*.frame_size  =  170ms 

[Run  18] 

output-vector-file  =  codeclS.vec 
*.frame_size  =  180ms 

[Run  19] 

output-vector-file  =  codecl9.vec 
*.frame_size  =  190ms 

[Run  20] 

output-vector-file  =  codec20.vec 
*.frame_size  =  200ms 

[Run  21] 

output-vector-file  =  codec21.vec 
*.frame_size  =  210ms 

[Run  22] 

output-vector-file  =  codec22.vec 
*.frame_size  =  220ms 

[Run  23] 

output-vector-file  =  codec23.vec 
*.frame_size  =  230ms 
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[Run  24] 


output-vector-file  =  codec24.vec 
* . f rame_size  =  240ms 

[Run  25] 

output-vector-file  =  codec25.vec 
*.frame_size  =  250ms 

[Run  26] 

output-vector-file  =  codec26.vec 
*.frame_size  =  260ms 

[Run  27] 

output-vector-file  =  codec27.vec 
*.frame_size  =  270ms 

[Run  28] 

output-vector-file  =  codec28.vec 
*.frame_size  =  280ms 

[Run  29] 

output-vector-file  =  codec29.vec 
*.frame_size  =  290ms 
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[Run  30] 


output-vector-file  =  codecSO.vec 
*.frame_size  =  300ms 

[Run  31] 

output-vector-file  =  codec31.vec 
*.frame_size  =  310ms 

[Run  32] 

output-vector-file  =  codec32.vec 
*.frame_size  =  320ms 

[Run  33] 

output-vector-file  =  codec33.vec 
*.frame_size  =  330ms 

[Run  34] 

output-vector-file  =  codec34.vec 
*.frame_size  =  340ms 

[Run  35] 

output-vector-file  =  codec35.vec 
*.frame_size  =  350ms 


[Run  36] 
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output-vector-file  =  codec36.vec 
*.frame_size  =  360ms 

[Run  37] 

output-vector-file  =  codec37.vec 
*.frame_size  =  370ms 

[Run  38] 

output-vector-file  =  codec38.vec 
*.frame_size  =  380ms 

[Run  39] 

output-vector-file  =  codec39.vec 
*.frame_size  =  390ms 

[Run  40] 

output-vector-file  =  codec40.vec 
*.frame_size  =  400ms 

[Run  41] 

output-vector-file  =  codec41.vec 
*.frame_size  =  410ms 

[Run  42] 

output-vector-file  =  codec42.vec 
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*.frame_size  =  420ms 

[Run  43] 

output-vector-file  =  codec43.vec 
*.frame_size  =  430ms 

[Run  44] 

output-vector-file  =  codec44.vec 
*.frame_size  =  440ms 

[Run  45] 

output-vector-file  =  codec45.vec 
*.frame_size  =  450ms 

[Run  46] 

output-vector-file  =  codec46.vec 
*.frame_size  =  460ms 

[Run  47] 

output-vector-file  =  codec47.vec 
*.frame_size  =  470ms 

[Run  48] 

output-vector-file  =  codec48.vec 
*.frame_size  =  480ms 
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[Run  49] 


output-vector-file  =  codec49.vec 
*.frame_size  =  490ms 

[Run  50] 

output-vector-file  =  codec50.vec 
*.frame_size  =  500ms 

// - 

//  file:  slow.ned 

//  author:  James  Knoll 

// 

//  Date:  31  May,  2004 

// 

//  Simple  voip  configuration  to  test  if  tcp  data  traffic 
//  can  be  modeled  using  the  UDP  application  developed.  It 
//  consists  of  a  variable  number  of  clients  with 
/ /  corresponding  servers  and  a  variable  number  of  voip 
//  conversations.  Various  loading  conditions  are 
//  accomplished  by  changing  the  number  of  TCP  and  voip 
//  clients  in  each  run.  The  current  limit  is  4  voip  nodes 
//  and  up  to  25  total  nodes  per  network  but  can  easily  be 
//  increased  if  needed. 


// 
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import 


"Router" , 

"TCPClientNode", 

"TCPServerNode" , 

"voipUDPHost", 

"INE", 

"wredBox" ; 

module  slow 

parameters : 

clients_netl  :  numeric  const,  //number  of  clients 
on  network  1 

clients_net2  :  numeric  const,  //number  of  clients 
on  network  2 

voip_client s :  numeric  const,  //number  of  voip 

pairs 

sat_datarate  :  numeric  const,  //data  rate  of 

satellite 

sat_error  :  numeric  const,  //BER  for  satellite 

sat_delay  :  numeric  const;  //delay  for  satellite 

submodules : 

voipclientl:  voipUDPHost  [ voip_client s ] ; 
parameters : 
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local_port  =  100 


dest_port  =  200, 

/ /  Voice  parameters 

voice_length  =  input (30s,  "Length  of  voice 
transmission:  "), 

initiate  =  input  (false,  "Initiate 

conversation?  "), 

codec_rate  =  input  (64000,  "CODEC  stream 

rate :  " ) , 

reply_delay  =  input  (4s,  "Time  to  delay 
before  replying  to  a  voice  burst:  "), 

frame_size  =  input (20ms,  "Length  of  a 

frame :  " ) , 

/ /  network  parameters 

numOfPorts  =  1;  //nodes  to  connect  to 
parameters  if  index==0 : 

local_addr  =  "10.0.0.1", 
dest_addr  =  "10.0.3.1", 
routingFile  =  "nodel_l . irt " ; 
parameters  if  index==l : 

local_addr  =  "10.0.0.2", 
dest_addr  =  "10.0.3.2", 
routingFile  =  " node 1_2 . irt " ; 
parameters  if  index==2 : 

local_addr  =  "10.0.0.3", 
dest_addr  =  "10.0.3.3", 
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routingFile  =  "nodel_3 . irt " ; 
parameters  if  index==3 : 

local_addr  =  "10.0.0.4", 
dest_addr  =  "10.0.3.4", 
routingFile  =  "nodel_4 . irt " ; 
gatesizes : 
in[l] , 
out  [  1 ] ; 

display :  "p=4  0 ,  1 60 , row; i=pc" ; 
inel:  INF  [ voip_client s ] ; 

display :  "p=4  0 , 2  0  0 , row; i=ipc" ; 
voipclient2:  voipUDPHost  [ voip_client s ] ; 
parameters : 

local_port  =  200, 
dest_port  =  100, 

/ /  Voice  parameters 

voice_length  =  input (30s,  "Length  of  voice 
transmission:  "), 

initiate  =  input  (false,  "Initiate 

conversation?  "), 

codec_rate  =  input  (64000,  "CODEC  stream 

rate :  " ) , 

reply_delay  =  input  (4s,  "Time  to  delay 
before  replying  to  a  voice  burst:  "), 

frame_size  =  input (20ms,  "Length  of  a 


frame:  ") 
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/ /  network  parameters 


numOfPorts  =  1;  //nodes  to  connect  to 
parameters  if  index==0 : 

local_addr  =  "10.0.3.1", 
dest_addr  =  "10.0.0.1", 
routingFile  =  "node2_l . irt " ; 
parameters  if  index==l : 

local_addr  =  "10.0.3.2", 
dest_addr  =  "10.0.0.2", 
routingFile  =  "node2_2 . irt " ; 
parameters  if  index==2 : 

local_addr  =  "10.0.3.3", 
dest_addr  =  "10.0.0.3", 
routingFile  =  "node2_3 . irt " ; 
parameters  if  index==3 : 

local_addr  =  "10.0.3.4", 
dest_addr  =  "10.0.0.4", 
routingFile  =  "node2_4 . irt " ; 
gatesizes : 
in[l] , 
out  [  1  ] ; 

display :  "p=4 0 , 34 0 , row; i=pc" ; 
ine2 :  INF  [ voip_client s ] ; 

display :  "p=40,300,row;i=ipc"; 

tcpclientl :  TCPClientNode [clients_netl ] ; 
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parameters : 


/ /  TCP  parameters 

local_addr  =  (10  <<  24) 

1 +voip_cl lent s+ index, 

server_addr  =  (10  <<24)  +(3 

l+voip_client s+index+client s_net2 , 

/ /  network  parameters 

numOfPorts  =  1;  //nodes  to  connect  to 
parameters  if  index+voip_client s==0 : 

routingFile  =  "nodel_l . irt " ; 
parameters  if  index+voip_client s==l : 

routingFile  =  " node 1_2 . irt " ; 
parameters  if  index+voip_client s==2 : 

routingFile  =  "nodel_3 . irt " ; 
parameters  if  index+voip_client s==3 : 

routingFile  =  "nodel_4 . irt " ; 
parameters  if  index+voip_client s==4 : 

routingFile  =  "nodel_5 . irt " ; 
parameters  if  index+voip_client s==5 : 

routingFile  =  "nodel_6 . irt " ; 
parameters  if  index+voip_client s==6 : 

routingFile  =  "nodel_7 . irt " ; 
parameters  if  index+voip_client s==7 : 

routingFile  =  "nodel_8 . irt " ; 
parameters  if  index+voip_client s==8 : 


+ 


<<8)  + 


223 


routingFile  =  "nodel_9 . irt " ; 


parameters  if  index+voip_client s==9 : 

routingFile  =  "nodel_l 0 . irt " ; 
parameters  if  index+voip_client s==l 0 
routingFile  =  "nodel_l 1 . irt " ; 
parameters  if  index+voip_client s==l 1 
routingFile  =  "nodel_12 . irt " ; 
parameters  if  index+voip_client s==12 
routingFile  =  "nodel_13 . irt " ; 
parameters  if  index+voip_clients==13 
routingFile  =  "nodel_14 . irt " ; 
parameters  if  index+voip_clients==14 
routingFile  =  "nodel_15 . irt " ; 
parameters  if  index+voip_clients==15 
routingFile  =  "nodel_l 6 . irt " ; 
parameters  if  index+voip_client s==l 6 
routingFile  =  "nodel_17 . irt " ; 
parameters  if  index+voip_clients==17 
routingFile  =  "nodel_l 8 . irt " ; 
parameters  if  index+voip_client s==l 8 
routingFile  =  "nodel_l 9 . irt " ; 
parameters  if  index+voip_client s==l 9 
routingFile  =  "nodel_2 0 . irt " ; 
parameters  if  index+voip_client s==2 0 

routingFile  =  "nodel_2 1 . irt " ; 
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parameters  if  index+voip_client s==2 1 : 

routingFile  =  "nodel_22 . irt " ; 
parameters  if  index+voip_client s==22 : 

routingFile  =  "nodel_23 . irt " ; 
parameters  if  index+voip_clients==23 : 

routingFile  =  "nodel_24 . irt " ; 
parameters  if  index+voip_clients==24 : 

routingFile  =  "nodel_25 . irt " ; 
gatesizes : 
in[l] , 
out  [  1 ] ; 

display:  "p=40,40,row;i=pc"; 
tcpclient2 :  TCPClientNode [ client s_net 2 ] ; 
parameters : 

/ /  TCP  parameters 

local_addr  =  (10  <<  24)  +(3 

1 +voip_cl lent s+ index, 

server_addr  =  (10  <<24) 

1 +voip_cl lent s+index+cl lent s_netl , 

/ /  network  parameters 

numOf Ports  =  1; 

parameters  if  index+voip_client s==0 : 

routingFile  =  "node2_l . irt " ; 
parameters  if  index+voip_client s==l : 
routingFile  =  "node2_2 . irt " ; 


<<8)  + 


+ 
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parameters  if  index+voip_client s==2 : 


routingFile  =  "node2_3 . irt " ; 

parameters  if  index+voip_client s==3 : 

routingFile  =  "node2_4 . irt " ; 

parameters  if  index+voip_client s==4 : 

routingFile  =  "node2_5 . irt " ; 

parameters  if  index+voip_client s==5 : 

routingFile  =  "node2_6 . irt " ; 

parameters  if  index+voip_client s==6 : 

routingFile  =  "node2_7 . irt " ; 

parameters  if  index+voip_client s==7 : 

routingFile  =  "node2_8 . irt " ; 

parameters  if  index+voip_client s==8 : 

routingFile  =  "node2_9 . irt " ; 

parameters  if  index+voip_client s==9 : 

routingFile  =  "node2_l 0 . irt " ; 

parameters  if  index+voip_client s==l 0 

routingFile  =  "node2_l 1 . irt " ; 

parameters  if  index+voip_client s==l 1 

routingFile  =  "node2_12 . irt " ; 

parameters  if  index+voip_client s==12 

routingFile  =  "node2_13 . irt " ; 

parameters  if  index+voip_clients==13 

routingFile  =  "node2_14 . irt " ; 

parameters  if  index+voip_clients==14 
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routingFile  =  "node2_15 . irt " ; 


parameters  if  index+voip_clients==15 
routingFile  =  "node2_l 6 . irt " ; 
parameters  if  index+voip_client s==l 6 
routingFile  =  "node2_17 . irt " ; 
parameters  if  index+voip_clients==17 
routingFile  =  "node2_l 8 . irt " ; 
parameters  if  index+voip_client s==l 8 
routingFile  =  "node2_l 9 . irt " ; 
parameters  if  index+voip_client s==l 9 
routingFile  =  "node2_2 0 . irt " ; 
parameters  if  index+voip_client s==2 0 
routingFile  =  "node2_2 1 . irt " ; 
parameters  if  index+voip_client s==2 1 
routingFile  =  "node2_22 . irt " ; 
parameters  if  index+voip_client s==22 
routingFile  =  "node2_23 . irt " ; 
parameters  if  index+voip_clients==23 
routingFile  =  "node2_24 . irt " ; 
parameters  if  index+voip_clients==24 
routingFile  =  "node2_25 . irt " ; 
gatesizes : 
in[l] , 
out  [  1  ]  ; 

display :  "p=4  0 , 4  60 , row; i=pc" ; 

227 


tcpserverl :  TCPServerNode [clients_netl ] ; 
parameters : 

parameters : 

/ /  TCP  parameters 

local_addr  =  (10  <<24)  +(3  <<8)+ 

l+voip_client s+index+client s_net2 , 

/ /  network  parameters 

numOfPorts  =  1; 

parameters  if  ( index+client s_net2+voip_client s ) 

==0  : 

routingFile  =  "node2_l . irt " ; 
parameters  if  ( index+client s_net2+voip_client s ) 

==1 : 

routingFile  =  "node2_2 . irt " ; 
parameters  if  ( index+client s_net2+voip_client s ) 

==2  : 

routingFile  =  "node2_3 . irt " ; 
parameters  if  ( index+client s_net2+voip_client s ) 

==3: 

routingFile  =  "node2_4 . irt " ; 
parameters  if  ( index+client s_net2+voip_client s ) 

==4  : 

routingFile  =  "node2_5 . irt " ; 
parameters  if  ( index+client s_net2+voip_client s ) 

==5  : 

routingFile  =  "node2_6 . irt " ; 
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parameters  if  ( index+client s_net2+voip_client s ) 


routingFile  =  "node2_7 . irt " ; 
parameters  if  ( index+client s_net2+voip_client s ) 


routingFile  =  "node2_8 . irt " ; 
parameters  if  ( index+client s_net2+voip_client s ) 


routingFile  =  "node2_9 . irt " ; 
parameters  if  ( index+client s_net2+voip_client s ) 


routingFile  =  "node2_l 0 . irt " ; 
parameters  if  ( index+client s_net2+voip_client s ) 


routingFile  =  "node2_l 1 . irt " ; 
parameters  if  ( index+client s_net2+voip_client s ) 


routingFile  =  "node2_12 . irt " ; 
parameters  if  ( index+client s_net2+voip_client s ) 


routingFile  =  "node2_13 . irt " ; 
parameters  if  ( index+client s_net2+voip_client s ) 


routingFile  =  "node2_14 . irt " ; 
parameters  if  ( index+client s_net2+voip_client s ) 


routingFile  =  "node2_15 . irt "  ; 
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parameters  if  ( index+client s_net2+voip_client s ) 


routingFile  =  "node2_l 6 . irt " ; 
parameters  if  ( index+client s_net2+voip_client s ) 


routingFile  =  "node2_17 . irt " ; 
parameters  if  ( index+client s_net2+voip_client s ) 


routingFile  =  "node2_l 8 . irt " ; 
parameters  if  ( index+client s_net2+voip_client s ) 


routingFile  =  "node2_l 9 . irt " ; 
parameters  if  ( index+client s_net2+voip_client s ) 


routingFile  =  "node2_2 0 . irt " ; 
parameters  if  ( index+client s_net2+voip_client s ) 


routingFile  =  "node2_2 1 . irt " ; 
parameters  if  ( index+client s_net2+voip_client s ) 


routingFile  =  "node2_22 . irt " ; 
parameters  if  ( index+client s_net2+voip_client s ) 


routingFile  =  "node2_23 . irt " ; 
parameters  if  ( index+client s_net2+voip_client s ) 


routingFile  =  "node2_24 . irt "  ; 
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parameters  if  ( index+client s_net2+voip_client s ) 

==2  4  : 

routingFile  =  "node2_25 . irt " ; 
gatesizes : 
in[l] , 
out  [  1 ] ; 

display :  "p=4  0,400, row; i=comp" ; 
tcpserver2 :  TCPServerNode [ client s_net 2 ] ; 
parameters : 

parameters : 

/ /  TCP  parameters 

local_addr  =  (10  <<24)  + 

1 +voip_cl lent s+ index+client s_netl , 

/ /  network  parameters 

numOfPorts  =  1; 

parameters  if  (index+clients_netl+voip_clients) 

==0  : 

routingFile  =  "nodel_l . irt " ; 
parameters  if  (index+clients_netl+voip_clients) 

==1 : 

routingFile  =  " node 1_2 . irt " ; 
parameters  if  (index+clients_netl+voip_clients) 

==2  : 

routingFile  =  "nodel_3 . irt " ; 
parameters  if  (index+clients_netl+voip_clients) 
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routingFile  =  "nodel_4 . irt " ; 
parameters  if  (index+clients_netl+voip_clients) 


routingFile  =  "nodel_5 . irt " ; 
parameters  if  (index+clients_netl+voip_clients) 


routingFile  =  "nodel_6 . irt " ; 
parameters  if  (index+clients_netl+voip_clients) 


routingFile  =  "nodel_7 . irt " ; 
parameters  if  (index+clients_netl+voip_clients) 


routingFile  =  "nodel_8 . irt " ; 
parameters  if  (index+clients_netl+voip_clients) 


routingFile  =  "nodel_9 . irt " ; 
parameters  if  (index+clients_netl+voip_clients) 


routingFile  =  "nodel_l 0 . irt " ; 
parameters  if  (index+clients_netl+voip_clients) 


routingFile  =  "nodel_l 1 . irt " ; 
parameters  if  (index+clients_netl+voip_clients) 


routingFile  =  "nodel_12 . irt " ; 
parameters  if  (index+clients_netl+voip_clients) 


routingFile  =  "nodel_13 . irt " ; 
parameters  if  (index+clients_netl+voip_clients) 


routingFile  =  "nodel_14 . irt " ; 
parameters  if  (index+clients_netl+voip_clients) 


routingFile  =  "nodel_15 . irt " ; 
parameters  if  (index+clients_netl+voip_clients) 


routingFile  =  "nodel_l 6 . irt " ; 
parameters  if  (index+clients_netl+voip_clients) 


routingFile  =  "nodel_17 . irt " ; 
parameters  if  (index+clients_netl+voip_clients) 


routingFile  =  "nodel_l 8 . irt " ; 
parameters  if  (index+clients_netl+voip_clients) 


routingFile  =  "nodel_l 9 . irt " ; 
parameters  if  (index+clients_netl+voip_clients) 


routingFile  =  "nodel_2 0 . irt " ; 
parameters  if  (index+clients_netl+voip_clients) 


routingFile  =  "nodel_2 1 . irt " ; 
parameters  if  (index+clients_netl+voip_clients) 


routingFile  =  "nodel_22 . irt " ; 
parameters  if  (index+clients_netl+voip_clients) 

==22  : 

routingFile  =  "nodel_23 . irt " ; 
parameters  if  (index+clients_netl+voip_clients) 

==2  3: 

routingFile  =  "nodel_24 . irt " ; 
parameters  if  (index+clients_netl+voip_clients) 

==2  4  : 

routingFile  =  "nodel_25 . irt " ; 
gatesizes : 
in[l] , 
out  [  1 ] ; 

display :  "p=4  0 ,  10  0, row; i=comp" ; 

routerl :  Router; 
parameters : 

/ /  network  parameters 
numOfPorts 

1 +voip_cl lent s+cl lent s_netl+cl lent s_net 2 , 

routingFile  =  "routerl . irt " ; 
gatesizes : 

in [ 1 +VO ip_cl lent s+cl lent s_netl+cl lent s_net 2 ] , 

out [ l+voip_clients+clients_net l+clients_net2 ] ; 
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display:  "p=14 0 , 22 0 ; i=ipc" ; 


router2 :  Router; 
parameters : 

/ /  network  parameters 

numOfPorts  = 

1 +voip_cl lent s+cl lent s_netl+cl lent s_net 2 , 

routingFile  =  "router2 . irt " ; 

gatesizes : 

in [ 1 +VO ip_cl lent s+cl lent s_netl+cl lent s_net 2 ] , 

out [ l+voip_clients+clients_net l+clients_net2 ] ; 
display:  "p=14 0 , 2 8 0 ; i=ipc" ; 

wredl :  wredBox; 
parameters : 

win  =  2s,  //window  size  for  bw  calcs 

bw_max  =  input  (42000,  "Max  amount  of  bw  to 
allocate  to  high  pri  traffic:  " ) ; 

display :  "b=l 6, 15 ; p=l 0  0 , 250 ; i=bwxcon_s " ; 

wred2 :  wredBox; 

parameters : 

win  =  2s,  //window  size  for  bw  calcs 

bw_max  =  input  (42000,  "Max  amount  of  bw  to 
allocate  to  high  pri  traffic:  "); 

display :  "b=l 6, 15 ; p=l 8  0 , 250 ; i=bwxcon_s " ; 
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connections  nocheck: 
for  i=l . . voip_client s  do  //network  1 

voipclient 1 [ i-1 ] . out [ 0 ]  -->  inel[i-l].plainln; 
inel  [ i-1 ]  . cypherOut  -->  routerl . in  [ i ] ; 
routerl . out [ i ]  -->  inel[i-l].cypherln; 
inel [ i-1 ]. plainOut  -->  voipclient 1 [ i-1 ]. in [ 0 ]  ; 
endf or ; 

for  1=1 . . voip_client s  do  //network  2 

voipclient2 [ i-1 ] . out [ 0 ]  -->  ine2[i-l].plainln; 
ine2 [ i-1 ]. cypherOut  -->  router2.in[i]; 
router2 . out [ 1 ]  -->  ine2[i-l].cypherln; 
ine2 [ i-1 ]. plainOut  -->  voipclient2 [ i-1 ] . in [ 0 ] ; 
endf or ; 

for  1=1 . . clients_net 1  do  //network  1 

tcpclient 1 [ i-1 ] . out [ 0 ]  --> 

routerl . in [ i+voip_client s ] ; 

t cpserverl [ i-1 ] . out [ 0 ]  --> 

router 2 . in [ i+client s_net2+voip_client s ] ; 

routerl . out [ i+voip_clients ]  -->  tcpclient 1 [ i- 

l].in[0]; 

router 2 . out [ i+client s_net 2 +voip_cl lent s ]  --> 

t cpserverl [i-1] .in[0]; 
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endf  or  ; 


for  i=l .. client s_net2  do  //network  2 

t cpclient2 [ i-1 ] . out [ 0 ]  --> 

router 2 . in [ i+voip_client s ] ; 

t cpserver2 [ i-1 ] . out [ 0 ]  --> 

routerl . in [ i+cl lent s_netl+voip_cl lent s ] ; 

router2 . out [ i+voip_client s ]  -->  tcpclient2 [ i- 

l]  .in[0]  ; 

routerl . out [ i+cl lent s_netl+voip_cl lent s ]  --> 

tcpserver2 [i-1] .in[0]; 

endf or; 


routerl . out [ 0 ]  -->  wredl.qln; 

wredl.qOut  -->  datarate  sat_datarate  error 
sat_error  delay  sat_delay  -->  wred2 .passin; 

wred2 . passOut  -->  router2 . in [ 0 ] ; 


router2 . out [ 0 ]  -->  wred2.qln; 

wred2.qOut  -->  datarate  sat_datarate  error 
sat_error  delay  sat_delay  -->  wredl .passin; 

wredl . passOut  -->  routerl . in [0]; 


endmodule 


network  directnw  :  slow 


237 


endnetwork 


# - 

#  filename:  omnetpp.ini 

#  ini  file  for  slow.ned 

#  author:  James  Knoll 

#  - 


[General ] 

preload-ned-f lies  =  *.ned  . . /mynodes/* . ned 

@c : /home/ IPSuite/nedf lies . 1st  ;  ned  files  to  load 

dynamically 

network  =  directnw 

total-stack-kb=7535 

sim-t ime-limit  =  10m  ;maximum  simulation  time  to  run 

simulation 

cpu-t ime-limit=  30m  ;maximum  clock  time  to  run  simulation 
random-seed  =  1  ; seed  for  random  numbers 

snapshot-file  =  tcpip.sna  ;file  to  output  snapshots  to 
; output-vector-file  =  tcpip.vec  ;file  to  output  vectors 


[Cmdenv] 

runs-to-execute=l-4  ; runs  to  execute  using  cmd  environment 
express-mode  =  yes  ; run  in  express  mode 


238 


status-f requency=l 0 0 0 0 0  ; frequency  for  status  messages 


[ Tkenv] 

def ault-run=l  ; run  to  execute  for  TK  environment 

[OutVectors ] 

interval  =  10s  ; delay  before  starting  to  record  data 

#voip  and  traffic  vectors 
*. delay_time . enabled  =  no 
*. receive_rate . enabled  =  no 
*. inst_rec_rate . enabled  =  no 
*. send_rate . enabled  =  no 
*. inst_send_rate . enabled  =  no 

*. j itter . enabled  =  no  ; jitter  in  voip  apps 

#tcp  client  vectors 

*.Send  No. enabled  =  no 

*.TCP  delay . enabled  =  no 

*.Rec  No. enabled  =  no 

*.Rec  Seq  No. enabled  =  no 

* . Cwnd  size. enabled  =  no 

*. Goodput . enabled  =  no 

*. Avg_Goodput . enabled  =  no 

*. Rec_Bits . enabled  =  no 


#wred  vectors 
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* . LP_BW . enabled 


no 


*. HP_BW . enabled  =  yes 
*. HPQ_size . enabled  =  no 
*. LPQ_size . enabled  =  no 


[Parameters ] 

#connect ions 

* . sat_datarate  =  64000  ;data  rate  of  satellite  connection 
*.sat_error  =  0  ; satellite  BER 

*.sat_delay  =  500ms  ; delay  in  satellite  link 


#traf f ic 

*.msg_length  =  11200 
* . traf f ic_rate  =  64000 


; length  of  a  message  in  bits 
;  rate  of  transmission 


#  voip  app  configuration 

* . voip_client s  =  3 

* . voice_length  =  30s 

; * . voipclient 1 [ 0 ] .initiate 
initiate  the  conversation 

* . voipclient2 [ 0 ] .initiate 

; * . voipclient 1 [ 1 ] .initiate 

* . voipclient2 [ 1 ] .initiate 

; * . voipclient 1 [ 2 ] .initiate 

* . voipclient2 [ 2 ] .initiate 


burst 
client 

false 

true 

false 

true 

false 
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; number  of  voip  clients 
; length  of  a  voice 
true  ;does  this 


*. voipclientl [ 3 ]. initiate  =  false 
*. voipclient2 [ 3 ]. initiate  =  false 

*. voipclientl [ 0 ]. codec_rate  =  5300  ;data  rate  for  voip 
client 

* . voipclient2 [ 0 ] . codec_rate  =  5300 
*. voipclientl [ 1 ]. codec_rate  =  5300 
* . voipclient2 [ 1 ] . codec_rate  =  5300 
*. voipclientl [ 2 ]. codec_rate  =  16000 
* . voipclient2 [ 2 ] . codec_rate  =  16000 
*. voipclientl [ 3 ]. codec_rate  =  16000 
* . voipclient2 [ 3 ] . codec_rate  =  16000 
* . reply_delay  =  4s  ; delay  before  sending  a  reply 
*.frame_size  =  140ms  ;size  of  a  frame 

*.init_delay  =  4s  ; delay  before  first  burst 
*.talk_cycle  =  50  ;percent  off  hook 
* . call_length  =  30m  ; length  of  a  call 

#wredbox 

*.bw_max  =  48000  ;48  for  64k  and  75  for  128k 

* • hpq_min_thresh  =  40  ;when  to  start  random  drop 
* • hpq_max_thresh  =  64  ;max  drop 
*.hpq_mpd  =  10  ; percent  to  drop 

* . lpq_min_thresh  =  20  ;when  to  start  random  drop 
* . lpq_max_thresh  =  34  ;max  drop 
* . lpq_mpd  =  10  ; percent  to  drop 
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*.max_q_len  =  64  ;max  queue  depth 
*.n  =  .01  ; weighting  factor 


#  TCP 

; * . clients_net 1  =  2  ; number  of  tcp  clients  in  network  1 
*. client s_net2  =  0  ; number  of  tcp  clients  in  network  2 
*.mss=1400  ;maximum  segment  size 

* . tcp . debug=true  ; debug  on 

* . message_length  =  64000000  ; length  of  message  to  transmit 

#  processing  delays  for  all  nodes 
* . preRout ing . procdelay  =  0 

* . rout ing . procdelay  =  0.2  us 
*. localDeliver . procdelay  =  1  us 
*. send . procdelay  =  0.5  us 
*. fragmentation . procdelay  =  0.1  us 
*. icmp . procdelay  =  0 
*. tunneling . procdelay  =  0 
*. mult least . procdelay  =  0 
*. output [*]. procdelay  =  0.2  us 
*. inputQueue . procdelay  =  0.1  us 
*. networkinterf ace . procdelay  =  0 

#  hook  names 
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* . qosBehaviorClass  =  "EnqueueWithoutQoS "  ; only 

currently  implemented  in  IPSuite 

#conf igurat ion  changes  between  runs 
[Run  1] 

* . clients_net 1  =  3 
*. voipclientl [ 0 ]. initiate  =  false 
*. voipclientl [ 1 ]. initiate  =  false 
*. voipclientl [ 2 ]. initiate  =  true 
output-vector-file  =  tcpipl.vec 

[Run  2] 

* . clients_net 1  =  18 
*. voipclientl [ 0 ]. initiate  =  false 
*. voipclientl [ 1 ]. initiate  =  false 
*. voipclientl [ 2 ]. initiate  =  true 
output-vector-file  =  tcpip2.vec 

[Run  3] 

* . clients_net 1  =  1 
*. voipclientl [ 0 ]. initiate  =  true 
*. voipclientl [ 1 ]. initiate  =  true 
*. voipclientl [ 2 ]. initiate  =  true 
output-vector-file  =  tcpip3.vec 


hook 
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[Run  4] 


* . clients_net 1  =  3 
*. voipclientl [ 0 ]. initiate  =  false 
*. voipclientl [ 1 ]. initiate  =  false 
*. voipclientl [ 2 ]. initiate  =  false 
output-vector-file  =  tcpip4.vec 

// - 

//  file:  trades. ned 
//  author:  James  Knoll 
// 

//  Date:  31  May,  2004 

// 

//  A  simple  voip  network  to  test  the  amount  of  data 
//  throughput  with  varying  voip  configurations.  The  UDP 
//  application  provides  network  traffic  that  can  be 
//  adjusted  with  the  data  rate.  The  number  of  voip  nodes 
//  is  currently  limited  to  12,  but  this  can  easily  be 
//  expanded.  Runs  are  configured  to  vary  the  call  cycle 
//  for  each  configuration  to  examine  how  the  configuration 
//  compares  against  the  standard  32k  of  data. 

// - 

import 


"Router" , 
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"TCPClientNode" 


"TCPServerNode" , 
"voipUDPHost", 

"INE", 

"wredBox" ; 


module  trades 
parameters : 

voip_client s 
sat_datarate 
sat_error  : 
sat_delay  : 


:  numeri 

c  const. 

/ / number 

:  numer 

ic  const. 

/ / satell 

numeric 

const , 

/ / satell 

numeric 

const ; 

/ / satell 

of  voip  pairs 
ite  data  rate 
ite  BER 
ite  delay 


submodules : 

voipclientl:  voipUDPHost  [ voip_client s ] ; 
parameters : 

local_port  =  100, 
dest_port  =  200, 

/ /  Voice  parameters 

voice_length  =  input (30s,  "Length  of  voice 
transmission:  "), 


initiate 

conversation?  "), 

codec_rate 

rate :  " ) , 


input (false,  "Initiate 


input  (64000,  "CODEC  stream 
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reply_delay  =  input  (4s,  "Time  to 
before  replying  to  a  voice  burst:  "), 

frame_size  =  input (20ms,  "Length 

frame :  " ) , 

/ /  network  parameters 
numOfPorts  =  1; 
parameters  if  index==0 : 

local_addr  =  "10.0.0.2", 
dest_addr  =  "10.0.3.2", 
routingFile  =  "nodel_2 . irt " ; 
parameters  if  index==l : 

local_addr  =  "10.0.0.3", 
dest_addr  =  "10.0.3.3", 
routingFile  =  "nodel_3 . irt " ; 
parameters  if  index==2 : 

local_addr  =  "10.0.0.4", 
dest_addr  =  "10.0.3.4", 
routingFile  =  "nodel_4 . irt " ; 
parameters  if  index==3 : 

local_addr  =  "10.0.0.5", 
dest_addr  =  "10.0.3.5", 
routingFile  =  "nodel_5 . irt " ; 
parameters  if  index==4 : 

local_addr  =  "10.0.0.6", 
dest_addr  =  "10.0.3.6", 


delay 


of  a 
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rout ingFile 


"nodel_6 . irt " 


parameters  if  index==5 : 

local_addr  =  "10.0.0 

dest_addr  =  "10.0.3. 

routingFile  =  "nodel 

parameters  if  index==6: 

local_addr  =  "10.0.0 

dest_addr  =  "10.0.3. 

routingFile  =  "nodel 

parameters  if  index==7 : 

local_addr  =  "10.0.0 

dest_addr  =  "10.0.3. 

routingFile  =  "nodel 

parameters  if  index==8 : 

local_addr  =  "10.0.0 

dest_addr  =  "10.0.3. 

routingFile  =  "nodel 

parameters  if  index==9: 

local_addr  =  "10.0.0 

dest_addr  =  "10.0.3. 

routingFile  =  "nodel 

parameters  if  index==10: 

local_addr  =  "10.0.0 

dest_addr  =  "10.0.3. 

routingFile  =  "nodel 
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.7", 

7", 

_7 . irt " 

.8", 

8", 

_8 . irt " 

.9", 

9", 

_9 . irt " 

.10", 

10", 

_1 0 . irt 

.11", 

11", 

_1 1 . irt 

.12", 

12", 

_12 . irt 


gatesizes : 


in[l] , 
out  [  1 ] ; 

display :  "p=4  0 ,  1 60 , row; i=pc" ; 
inel:  INE  [ voip_client s ] ; 

display :  "p=4  0 , 2  0  0 , row; i=ipc" ; 
voipclient2:  voipUDPHost  [ voip_client s ] ; 
parameters : 

local_port  =  200, 
dest_port  =  100, 

/ /  Voice  parameters 

voice_length  =  input (30s,  "Length  of  voice 
transmission:  "), 

initiate  =  input  (false,  "Initiate 

conversation?  "), 

codec_rate  =  input  (64000,  "CODEC  stream 

rate :  " ) , 

reply_delay  =  input  (4s,  "Time  to  delay 
before  replying  to  a  voice  burst:  "), 

frame_size  =  input (20ms,  "Length  of  a 

frame :  " ) , 

/ /  network  parameters 
numOfPorts  =  1; 
parameters  if  index==0 : 

local_addr  =  "10.0.3.2", 
dest_addr  =  "10.0.0.2", 
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routingFile  =  "node2_2 . irt " ; 
parameters  if  index==l : 

local_addr  =  "10.0.3.3", 
dest_addr  =  "10.0.0.3", 
routingFile  =  "node2_3 . irt " ; 
parameters  if  index==2 : 

local_addr  =  "10.0.3.4", 
dest_addr  =  "10.0.0.4", 
routingFile  =  "node2_4 . irt " ; 
parameters  if  index==3 : 

local_addr  =  "10.0.3.5", 
dest_addr  =  "10.0.0.5", 
routingFile  =  "node2_5 . irt " ; 
parameters  if  index==4 : 

local_addr  =  "10.0.3.6", 
dest_addr  =  "10.0.0.6", 
routingFile  =  "node2_6 . irt " ; 
parameters  if  index==5 : 

local_addr  =  "10.0.3.7", 
dest_addr  =  "10.0.0.7", 
routingFile  =  "node2_7 . irt " ; 
parameters  if  index==6: 

local_addr  =  "10.0.3.8", 
dest_addr  =  "10.0.0.8", 

routingFile  =  "node2_8 . irt " ; 
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parameters  if  index==7 : 

local_addr  =  "10.0.3.9", 
dest_addr  =  "10.0.0.9", 
routingFile  =  "node2_9 . irt " ; 
parameters  if  index==8 : 

local_addr  =  "10.0.3.10", 
dest_addr  =  "10.0.0.10", 
routingFile  =  "node2_l 0 . irt " ; 
parameters  if  index==9: 

local_addr  =  "10.0.3.11", 
dest_addr  =  "10.0.0.11", 
routingFile  =  "node2_l 1 . irt " ; 
parameters  if  index==10: 

local_addr  =  "10.0.3.12", 
dest_addr  =  "10.0.0.12", 
routingFile  =  "node2_12 . irt " ; 
gatesizes : 
in[l] , 
out  [  1  ] ; 

display :  "p=4 0 , 34 0 , row; i=pc" ; 
ine2 :  INF  [ voip_client s ] ; 

display :  "p=40,300,row;i=ipc"; 

traf f icclient 1 :  traf f icUDPHost ; 


parameters : 
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local_addr  =  "10.0.0.1", 
dest_addr  =  "10.0.3.1", 
local_port  =  400, 
dest_port  =  500, 

msg_length  =  input  (12000,  "Maximum 
length (bit s ) :  "),  //1500  bytes 

start_delay  =  false, 

traffic_rate  =  input  (64000,  "Traffic 

rate :  " ) , 

/ /  network  parameters 
numOfPorts  =  1, 
routingFile  =  "nodel_l . irt " ; 
gatesizes : 
in[l] , 
out  [  1 ] ; 

display :  "p=14  0 ,  10  0,row;i=pc"; 
traf f icclient2 :  traf f icUDPHost ; 
parameters : 

/ /  UDP  parameters 
local_addr  =  "10.0.3.1", 
dest_addr  =  "10.0.0.1", 
local_port  =  400, 
dest_port  =  500, 

msg_length  =  input  (1500,  "Maximum 

length :  " ) , 


payload 


stream 


payload 
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//  traffic  parameters 


start_delay  =  false, 

traffic_rate  =  input  (64000,  "traffic 

rate :  " ) , 

/ /  network  parameters 
numOfPorts  =  1, 
routingFile  =  "node2_l . irt " ; 
gatesizes : 
in[l] , 
out [ 1 ] ; 

display :  "p=14  0 , 42  0 , row; i=pc" ; 

routerl :  Router; 

parameters : 

/ /  network  parameters 

numOfPorts  =  2+voip_client s , 

routingFile  =  "routerl . irt " ; 

gatesizes : 

in [ 2+voip_client s ] , 

out [ 2+voip_client s ] ; 

display:  "p=14 0 , 22 0 ; i=ipc" ; 

router2 :  Router; 

parameters : 

/ /  network  parameters 

numOfPorts  =  2+voip_client s , 
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stream 


routingFile  =  "router2 . irt " ; 


gatesizes : 

in [ 2+voip_client s ] , 
out [ 2+voip_client s ] ; 
display:  "p=14 0 , 2 8 0 ; i=ipc" ; 

wredl :  wredBox; 
parameters : 

win  =  2s, 

bw_max  =  input  (48000,  "Max  amount  of  bw  to 
allocate  to  high  pri  traffic:  " ) ; 

display :  "b=l 6, 15 ; p=l 0  0 , 250 ; i=bwxcon_s " ; 

wred2 :  wredBox; 

parameters : 

win  =  2s, 

bw_max  =  input  (48000,  "Max  amount  of  bw  to 
allocate  to  high  pri  traffic:  " ) ; 

display :  "b=l 6, 15 ; p=l 8  0 , 250 ; i=bwxcon_s " ; 

connections  nocheck: 

for  1=1 . . voip_client s  do  //network  1 

voipclient 1 [ 1-1 ] . out [ 0 ]  -->  inel[i-l].plainln; 
inel [ 1-1 ]  . cypherOut  -->  routerl . in [ i  +  1  ]  ; 
routerl . out [ i  +  1 ]  -->  inel  [ i-1 ]  . cypherin; 
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inel [ i-1 ] . plainOut  -->  voipclient 1 [ i-1 ] . in [ 0 ] ; 


endf or ; 

for  i=l . . voip_client s  do  //network  2 

voipclient2  [ i-1 ]  . out [ 0 ]  -->  ine2 [ i-1 ]  . plainin 
ine2 [ i-1 ] . cypherOut  -->  router2 . in [ i+1 ] ; 
router2 . out [ i+1 ]  -->  ine2[i-l].cypherln; 
ine2 [ i-1 ]. plainOut  -->  voipclient2 [ i-1 ] . in [ 0 ] 

endfor; 

traf f icclient 1 . out  -->  routerl . in [ 1 ]  ; 

traf f icclient 1 . in  <--  routerl . out [ 1 ] ; 

traf ficclient2 . out  -->  router2 . in [ 1 ] ; 

traf f icclient2 . in  <--  router2 . out [ 1 ] ; 

routerl . out [ 0 ]  -->  wredl.qln; 

wredl.qOut  -->  datarate  sat_datarate  error  sat. 
delay  sat_delay  -->  wred2 .passln; 

wred2 . passOut  -->  router2.in[0]; 

router2 . out [ 0 ]  -->  wred2.qln; 

wred2.qOut  -->  datarate  sat_datarate  error  sat. 
delay  sat_delay  -->  wredl .passln; 

wredl . passOut  -->  routerl . in [0]; 


error 


error 
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endmodule 


network  directnw  :  trades 
endnetwork 

# - 

#  filename:  omnetpp.ini 

#  ini  file  for  trades. ned 

#  author:  James  Knoll 

#  - 


[General ] 

preload-ned-f lies  =  *.ned  . . /mynodes/* . ned 

@c : /home/ IPSuite/nedf lies . 1st  ;  ned  files  to  load 

dynamically 

network  =  directnw 

total-stack-kb=7535 

sim-t ime-limit  =  Ih  ;maximum  simulation  time  to  run 
simulation 

cpu-t ime-limit=  30m  ;maximum  clock  time  to  run  simulation 
random-seed  =  1  ; seed  for  random  numbers 

snapshot-file  =  trades. sna  ;file  to  output  snapshots  to 
; output-vector-file  =  trades. vec  ;file  to  output  vectors 
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[Cmdenv] 


runs-to-execute=l-l 0  ; runs  to  execute  using  cmd 

environment 

express-mode  =  yes  ; run  in  express  mode 

status-f requency=l 0 0 0 0 0  ; frequency  for  status  messages 

[ Tkenv] 

def ault-run=l  ; run  to  execute  for  TK  environment 

[OutVectors ] 

*. interval  =  1000s  ; delay  before  starting  to  record  data 

#voip 

*. delay_time . enabled  =  no 

*. voipclientl [ 0 ].*. receive_rate . enabled  =  no 
*. voipclientl [ 1 ].*. receive_rate . enabled  =  no 
*. voipclientl [ 2 ].*. receive_rate . enabled  =  no 
*. voipclientl [ 3 ].*. receive_rate . enabled  =  no 
*. voipclient2 [ 0 ].*. receive_rate . enabled  =  no 
*. voipclient2 [ 1 ].*. receive_rate . enabled  =  no 
*. voipclient2 [ 2 ].*. receive_rate . enabled  =  no 
*. voipclient2 [ 3 ].*. receive_rate . enabled  =  no 
*. voipclientl [ 4 ].*. receive_rate . enabled  =  no 
*. voipclientl [ 5 ].*. receive_rate . enabled  =  no 
*. voipclientl [ 6 ].*. receive_rate . enabled  =  no 
*. voipclientl [ 7 ].*. receive_rate . enabled  =  no 
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*. voipclient2 [ 4 ].*. receive_rate . enabled  =  no 
*. voipclient2 [ 5 ].*. receive_rate . enabled  =  no 
*. volpcllent2 [ 6 ].*. recelve_rate . enabled  =  no 
*. volpcllent2 [ 7 ].*. recelve_rate . enabled  =  no 
*. trafflccllentl recelve_rate . enabled  =  no 
*. trafflccllent2 recelve_rate . enabled  =  yes 
*. lnst_rec_rate . enabled  =  no 
*. send_rate . enabled  =  no 
*. lnst_send_rate . enabled  =  no 

*. j Itter . enabled  =  no  ; jitter  In  volp  apps 

#tcp 

;*.Send  No. enabled  =  no 
;*.TCP  delay . enabled  =  no 
;*.Rec  No. enabled  =  no 
;*.Rec  Seq  No. enabled  =  no 
; * . Cwnd  size. enabled  =  no 
Goodput . enabled  =  no 
Avg_Goodput . enabled  =  no 
#wred 

*. LP_BW . enabled  =  no 
*. HP_BW . enabled  =  no 
*. HPQ_slze . enabled  =  no 
*. LPQ_slze . enabled  =  no 


[Parameters ] 
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#connect ions 


* . sat_datarate  =  64000  ;data  rate  of  satellite  connection 
*.sat_error  =  0  ; satellite  BER 

*.sat_delay  =  500ms  ; delay  in  satellite  link 

#traf f ic 

*.msg_length  =  11200 

*  .  traf f ic_rate  =  64000 

#  voip  app  configuration 

* . voip_client s  =  1  ; number  of  voip  clients 


* . voice_length 

3m 

; length  of  a  voice 

burst 

; * . voipclientl 

[0] 

. voice_length  = 

30s  ; length 

when 

silence  suppression  enabled 

; * . voipclientl 

[1] 

. voice_length  = 

3m 

; * . voipclientl 

[2] 

. voice_length  = 

3m 

; * . voipclientl 

[3] 

. voice_length  = 

3m 

; * . voipclient2 

[0] 

. voice_length  = 

30s 

; * . voipclient2 

[1] 

. voice_length  = 

3m 

; * . voipclient2 

[2] 

. voice_length  = 

3m 

; * . voipclient2 

[3] 

. voice_length  = 

3m 

* . voipclientl  [ 

0]  . 

initiate  =  true 

;does  this 

client 

initiate  the  conversation 
*. voipclient2 [ 0 ]. initiate  =  false 
*. voipclientl [ 1 ]. initiate  =  true 


; length  of  a  message  in  bits 
;  rate  of  transmission 
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*. voipclient2 [ 1 ]. initiate  =  false 
*. voipclientl [ 2 ]. initiate  =  true 
*. voipclient2 [ 2 ]. initiate  =  false 
*. voipclientl [ 3 ]. initiate  =  true 
*. voipclient2 [ 3 ]. initiate  =  false 
*. voipclientl [ 4 ]. initiate  =  true 
*. voipclient2 [ 4 ]. initiate  =  false 
*. voipclientl [ 5 ]. initiate  =  true 
*. voipclient2 [ 5 ]. initiate  =  false 
* .voipclientl [ 6] . initiate  =  true 
*. voipclient2 [ 6 ]. initiate  =  false 
*. voipclientl [ 7 ]. initiate  =  true 
*. voipclient2 [ 7 ]. initiate  =  false 

*. voipclientl [ 0 ]. codec_rate  =  16000  ;data  rate  for  voip 

client 

* . voipclient2 [ 0 ] . codec_rate  =  16000 
*. voipclientl [ 1 ]. codec_rate  =  16000 
* . voipclient2 [ 1 ] . codec_rate  =  16000 
*. voipclientl [ 2 ]. codec_rate  =  5300 
* . voipclient2 [ 2 ] . codec_rate  =  5300 
*. voipclientl [ 3 ]. codec_rate  =  5300 
* . voipclient2 [ 3 ] . codec_rate  =  5300 
*. voipclientl [ 4 ]. codec_rate  =  5300 
* . voipclient2 [ 4 ] . codec_rate  =  5300 
*. voipclientl [ 5 ]. codec_rate  =  5300 
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* . voipclient2 [ 5 ] . codec_rate  =  5300 


* . voipclientl [ 6] . codec_rate  =  5300 
* . voipclient2 [ 6 ] . codec_rate  =  5300 
*. voipclientl [ 7 ]. codec_rate  =  5300 
* . voipclient2 [ 7 ] . codec_rate  =  5300 
* . reply_delay  =  4s  ; delay  before  sending  a  reply 
*.frame_size  =  140ms  ;size  of  a  frame 

*.init_delay  =  Os  ; delay  before  first  burst 
;  * . talk_cycle  =  50  ;percent  off  hook 
* . call_length  =  30m  ; length  of  a  call 


#wredbox 

* . bw_max  =  48000 
* • hpq_min_thresh 
* • hpq_max_thresh 
* • hpq_mpd  =  10 
* • lpq_min_thresh 
* • lpq_max_thresh 
* • lpq_mpd  =  10 
*.max_q_len  =  64 
*  .  n  =  .  0 1  ; 


;48  for  64k  and  75  for  128k 
=  40  ;when  to  start  random  drop 

=  64  ;max  drop 

; percent  to  drop 

=  20  ;when  to  start  random  drop 

=  34  ;max  drop 

; percent  to  drop 
;max  queue  depth 
weighting  factor 


#  TCP 

; * . clients_net 1  =  2  ; number  of  tcp  clients  in  network  1 

=  0  ; number  of  tcp  clients  in  network  2 
260 


* . clients_net2 


* .mss=1400 


; maximum  segment  size 


* . tcp . debug=true  ; debug  on 

* . message_length  =  64000000  ; length  of  message  to  transmit 

#  processing  delays  for  all  nodes 
* . preRout ing . procdelay  =  0 

* . rout ing . procdelay  =  0.2  us 
*. localDeliver . procdelay  =  1  us 
*. send . procdelay  =  0.5  us 
*. fragmentation . procdelay  =  0.1  us 
*. icmp . procdelay  =  0 
*. tunneling . procdelay  =  0 
*. mult least . procdelay  =  0 
*. output [*]. procdelay  =  0.2  us 
*. inputQueue . procdelay  =  0.1  us 
*. networkinterf ace . procdelay  =  0 

#  hook  names 

* . qosBehaviorClass  =  "EnqueueWithoutQoS"  ; only  hook 
currently  implemented  in  IPSuite 

#conf igurat ion  changes  between  runs 
[Run  1] 

*.talk_cycle  =  100 

output-vector-file  =  tradesl.vec 

261 


[Run  2] 


*.talk_cycle  =  90 
output-vector-file  =  trades2.vec 

[Run  3] 

*.talk_cycle  =  80 
output-vector-file  =  tradesS.vec 

[Run  4] 

*.talk_cycle  =  70 
output-vector-file  =  trades!. vec 

[Run  5] 

*.talk_cycle  =  60 
output-vector-file  =  tradesS.vec 

[Run  6] 

*.talk_cycle  =  50 
output-vector-file  =  tradesG.vec 

[Run  7] 

*.talk_cycle  =  40 
output-vector-file  =  trades!. vec 
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[Run  8] 


*.talk_cycle  =  30 
output-vector-file  =  tradesS.vec 

[Run  9] 

*.talk_cycle  =  20 
output-vector-file  =  trades9.vec 

[Run  10] 

*.talk_cycle  =  10 

output-vector-file  =  tradeslO.vec 
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